Skip to content
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

Open
tilgovi opened this issue Oct 27, 2015 · 9 comments
Open

Comments #12

tilgovi opened this issue Oct 27, 2015 · 9 comments

Comments

@tilgovi
Copy link

tilgovi commented Oct 27, 2015

It would be nice to be able to store comments in IPFS and retrieve comments on web resources by querying IPFS.

@rht
Copy link

rht commented Oct 28, 2015

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.

@tilgovi
Copy link
Author

tilgovi commented Oct 28, 2015

Should we first discuss storing metadata, then aggregation?

@davidar
Copy link
Member

davidar commented Oct 28, 2015

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

/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...

@rht
Copy link

rht commented Oct 28, 2015

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 ipfs/notes#40 (comment)) 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)

@davidar
Copy link
Member

davidar commented Oct 29, 2015

@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.

@rht
Copy link

rht commented Oct 29, 2015

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.

@harlantwood
Copy link

Moderately related to ipfs-inactive/archives#34

@davidar
Copy link
Member

davidar commented Nov 7, 2015

@tilgovi I'm not sure if that answered your question?

@tilgovi
Copy link
Author

tilgovi commented Nov 9, 2015

I wasn't asking a question as much as making some placeholder for interest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants