-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments #12
Comments
This depends on how the computed object metadata is cached in the repo. |
Should we first discuss storing metadata, then aggregation? |
So, there's a few different issues relevant to this:
To post a comment, the best system would probably be to publish it under your IPNS address, like
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... |
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? Then the third one would be to centralize the aggregation (@reit-c's ipfs/notes#40 (comment)) while the storage remains distributed. (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. |
Moderately related to ipfs-inactive/archives#34 |
@tilgovi I'm not sure if that answered your question? |
I wasn't asking a question as much as making some placeholder for interest. |
It would be nice to be able to store comments in IPFS and retrieve comments on web resources by querying IPFS.
The text was updated successfully, but these errors were encountered: