ipfs
Comments
It would be nice to be able to store comments in IPFS and retrieve comments on web resources by querying IPFS.
This depends on how the computed object metadata is cached in the repo. This is also the case for search indexes, repo object count, object unixfs size, etc.
So, there's a few different issues relevant to this:
- storage itself
- discovery ipfs/notes#15
- aggregation ipfs/notes#40
To post a comment, the best system would probably be to publish it under your IPNS address, like
/ipns/<your peer-id>/<parent page id>/<your comment id>
That way, anyone who knows your PeerID (IPNS address) can retrieve your comments for any given page. Note that your IPNS address is just a (mutable, cryptographically signed) pointer to an IPFS object.
Discovering which PeerIDs have commented on some page (so that you can go and retrieve them) can piggyback off the Providers mechanism, as described in the linked issue. In a naive system, it's then up to the client to aggregate all the comments together in a sensible way. Obviously this won't scale if you have thousands of PeerIDs responding to your discovery request.
So, to deal with this there's two main approaches. As I mentioned on IRC, the way systems like zeronet approach this is to have an explicit whitelisting system whereby the site owner recieves requests from PeerIDs to comment on their site, and the (small) list of "approved" PeerIDs gets published alongside the site itself. This is pretty easy to implement (ignoring how the moderation itself functions), but clearly isn't an ideal solution for a variety of reasons.
Ideally we want a system that aggregates comments together in a decentralised way, which doesn't require either a centralised moderation system, or require every visitor to the site to be retrieving and aggregating comments from a large number of people. This is where all the CRDT magic being discussed in ipfs/notes#40 comes in...
So, to deal with this there's two main approaches.
The moderated approach (was this first stated in https://github.com/ipfs/ipfs/issues/31 ?) being the first one, then what is the other one? If I understand the CRDT discussion correctly (?), the recent discussion was about achieving decentralised aggregation through data structure with weak ordering. This is still heavily researched.
Then the third one would be to centralize the aggregation (@reit-c's https://github.com/ipfs/notes/issues/40#issuecomment-140764355) while the storage remains distributed. I'd say this is the form of the existing early-tier ipfs apps? Also, sufficiently anon comments are possible in either the first/third approach.
(note: were all the 'propagator's cited in the CRDT discussion specifically refer to http://groups.csail.mit.edu/mac/users/gjs/propagators/ ? Didn't make the connection until just now that while it is modeled after biological systems, its predecessor (actor model) was modeled after physical systems)
@rht yes, the "moderation" system could be automated and/or split across multiple nodes, as @reit-c suggested. I don't see this as being sufficiently different to be considered a separate "third" option. Note that in both the approaches I suggested above, the storage itself would indeed be distributed. By the second option I was referring to the CRDT discussion, which does currently have solutions for these types of problems, although some use cases (eg partial replication) do appear to do be open research problems.
I set it as a separate 3rd case because it doesn't require a whitelist (then maybe a captcha can be used to prevent bot flood). Sure you can split the aggregator across multiple nodes, but there is limit to this, imposed by the unmoderated network traffic.
I wasn't asking a question as much as making some placeholder for interest.