Support commenting for adventures

[nilclass]

It would be cool if there were a commenting features for the "adventures" section on unhosted.org. That way we can get some feedback if people actually understand what they are reading.

[hugoroy]

A commenting app using reamotestorage would be awesome (like disqus but decentralised)

[silverbucket]

I was thinking of doing something like this a few months ago, wrote out some sketches, but that was as far as I'd gotten, the most obvious option is to have each comment stored on the commentors remote storage. This would mean you'd need to sign up to a remoteStorage provider to leave a comment, and if you changed providers or they went down the comment would be lost.

Might be good to set up some kind of default fallback for people who just want to leave a comment without bothering to select a rs provider.

I agree this would be awesome to have -nick

On Fri, Jan 25, 2013 at 4:27 AM, Hugo Roy notifications@github.com wrote:

A commenting app using reamotestorage would be awesome (like disqus but decentralised)

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/26#issuecomment-12674423.

[nilclass]

When storing comments in remoteStorage, I guess the minimal requirement for the blog-poster would be to provide some kind of notification endpoint to link the comment to the blog post. This could be a sockethub instance, or a regular HTTP server.

[jancborchardt]

Also calling in @joar of http://talka.tv

[michielbdejong]

the official fedsocweb way would be with a salmon slap i think, and DialBack is a simplification of that. it would be fun to do it the proper way. i'll chew on it for a bit

[michielbdejong]

silly us, of course commenting functionality was supported all along. :)

Added the link under each blogpost now. So, comment away, guys! :)

[hugoroy]

Le lundi 04 février 2013 à 22:01 -0800, Michiel@unhosted a écrit :

silly us, of course commenting functionality was supported all along. :)

Added the link under each blogpost now. So, comment away, guys! :)

Well, not really unhosted... :(

Hugo Roy FSFE Legal Team Deputy Coordinator FSFE French Team Coordinator Support Free Software, sign up! https://fsfe.org/support

[jancborchardt]

Yeah, I agree with Hugo – commenting on the blog post could be a nice way of dogfooding for both you as author and for the commenters. Just like friendsunhosted.com works with comments on threads, your comments being stored in your remotestorage. @michielbdejong you could also look into collaborating with http://talka.tv for that, cc @joar.

Simply linking to Google Groups for that functionality seems like a bit of a cop-out, especially regarding the nature of the posts. Also, Google is evil, isn’t it? ;)

On Tue, Feb 5, 2013 at 2:42 PM, Hugo Roy notifications@github.com wrote:

Le lundi 04 février 2013 à 22:01 -0800, Michiel@unhosted a écrit :

silly us, of course commenting functionality was supported all along. :)

Added the link under each blogpost now. So, comment away, guys! :)

Well, not really unhosted... :(

Hugo Roy FSFE Legal Team Deputy Coordinator FSFE French Team Coordinator Support Free Software, sign up! https://fsfe.org/support

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/26#issuecomment-13129511.

[michielbdejong]

yeah, it's not trivial though. would have to implement http://tools.ietf.org/id/draft-prodromou-dialback-00.txt in sockethub.

talka.tv doesn't really solve any part of it think, because iiuc because we would need to run the talka.tv server, and people would have to create yet another account on there. it would be nice if people could use either their their sockethub account or their remotestorage account.

doing it with remoteStorage doesn't really fit the model because you don't want each blog to be able to edit your comments of all other blogs, and also you don't want to add one module per blog i think. you also don't want to create one centralized 'commenter' app. so then you need to add webintents i think.

if someone can find an example of how to combine webintents+dialback then i think that would be the way to go.

other options would be to allow commenting through Persona, WebID or OpenID.

And, yes!, very evil! :)

[michielbdejong]

oh, or salmon of course. http://www.salmon-protocol.org/ is salmon on your roadmap for sockethub, @silverbucket ? as soon as sockethub does salmon, then it makes sense to switch on salmon comments on the blog.

[silverbucket]

Perhaps I'm misunderstand, but what salmon looks like to me, is a mechanism for aggregators to let the source know there's a new comment - and publish it via. salmon. Also for the publisher to push to all subscribers/aggregators the new comments.

How does sockethub fit into this? It doesn't seem to have anything to do with a commenting system on a blog - it assumes that already exists.

I'm all for adopting it, but just don't understand what you mean by "sockethub doing salmon" :)

On Tue, Feb 5, 2013 at 3:44 PM, Michiel@unhosted notifications@github.comwrote:

oh, or salmon of course. http://www.salmon-protocol.org/ is salmon on your roadmap for sockethub, @silverbuckethttps://github.com/silverbucket? as soon as sockethub does salmon, then it makes sense to switch on salmon comments on the blog.

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/26#issuecomment-13132152..

[jancborchardt]

Yeah, but someone needs to do it, and it will probably take time to do it properly. The easy commenting solution is already working in friendsunhosted.com, and just having one comments module isn’t bad – how would we do it anyway?

On Tue, Feb 5, 2013 at 3:24 PM, Michiel@unhosted notifications@github.comwrote:

yeah, it's not trivial though. would have to implement http://tools.ietf.org/id/draft-prodromou-dialback-00.txt in sockethub.

talka.tv doesn't really solve any part of it think, because iiuc because we would need to run the talka.tv server, and people would have to create yet another account on there. it would be nice if people could use either their their sockethub account or their remotestorage account.

doing it with remoteStorage doesn't really fit the model because you don't want each blog to be able to edit your comments of all other blogs, and also you don't want to add one module per blog i think. you also don't want to create one centralized 'commenter' app. so then you need to add webintents i think.

if someone can find an example of how to combine webintents+dialback then i think that would be the way to go.

other options would be to allow commenting through Persona, WebID or OpenID.

And, yes!, very evil! :)

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/26#issuecomment-13131269..

[michielbdejong]

there's a piece missing from friendsunhosted's way of commenting because iiuc you can only see comments by people you follow? so the website would have to follow people before they comment, which is a bit hard. do you know how we could work around that @brolund ?

re @silverbucket letting the source know you published a comment is exactly what we need. the user would host the comment, and then send a salmon slap to the website. afaik you cannot send a salmon slap from an unhosted web app, because it needs to be cryptographically signed. so the outgoing slap would have to go through sockethub.

but as i said, i think this is really not that easy. i definitely think we should get email, irc, facebook and twitter working first, and also github and webrtc. Commenting, like user search, is a hard problem to solve. :)

[jancborchardt]

Yeah, the problem is that the user addresses or pointers of the people who commented would need to be saved somewhere. For friendsunhosted that’s in your own remotestorage, and for the blog that would need to be somewhere at the blog.

On Wed, Feb 6, 2013 at 3:25 AM, Michiel@unhosted notifications@github.comwrote:

there's a piece missing from friendsunhosted's way of commenting because iiuc you can only see comments by people you follow? so the website would have to follow people before they comment, which is a bit hard. do you know how we could work around that @brolund https://github.com/brolund ?

re @silverbucket https://github.com/silverbucket letting the source know you published a comment is exactly what we need. the user would host the comment, and then send a salmon slap to the website. afaik you cannot send a salmon slap from an unhosted web app, because it needs to be cryptographically signed. so the outgoing slap would have to go through sockethub.

but as i said, i think this is really not that easy. i definitely think we should get email, irc, facebook and twitter working first, and also github and webrtc. Commenting, like user search, is a hard problem to solve. :)

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/26#issuecomment-13163980.

[silverbucket]

Even though this is not a high priority for sockethub, lets continue to talk this through, if you don't mind. It's a healthy exercise :)

On Wed, Feb 6, 2013 at 3:25 AM, Michiel@unhosted notifications@github.com wrote:

re @silverbucket letting the source know you published a comment is exactly what we need. the user would host the comment, and then send a salmon slap to the website. afaik you cannot send a salmon slap from an unhosted web app, because it needs to be cryptographically signed. so the outgoing slap would have to go through sockethub.

... so the commenter would take on the role of aggregator or secondary publisher in this case. although they don't have a published copy of the source post, they are informing the source that there is a comment for them. this gist makes sense. however, based on my understanding of salmon, there are specific issues with this approach:

1. the protocol of salmon seems to be that it duplicates comments. when an aggregator notifies the source of a comment, it actually sends the comment, to be duplicated on the source. this would, in effect, no longer give the original commenter control over the copy of their comment which now lives in source post.
2. since the commenter takes on the role of aggregater, the salmon protocol defines the responsibility of the source to broadcast to all registered aggregators a copy of a comment whenever it's received. since, in our use case, the aggregator is a singer commenters remote storage location, this doesn't make any sense.
3. the salmon protocol would first need to be implemented in the blog software / http server of the source post, as well as the commentors remote storage provider, before it's of any use to sockethub... specifically:

3.a) the commenting app, which lives on the source, would require the user to log into their remote storage account and their sockethub account - this can be achieved if the useraddress webfinger resource has both their remote storage and sockethub details included. this implies remote storage providers would need to provide sockethub acconts for their users, and sockethub and remote storage become somewhat married. a user could always have their own webfinger resource for their vanity domain ie. nick@silverbucet.net, which specifies their own sockethub instance - however for most users this wont be the case, if all they have done is sign up for a 5apps account.

3.b) the source blog sould need to provide a salmon endpoint, and be able to write to the users remote storage with salmon data.

3.c) the commenters sockethub posts to the source salmon endpoint, they must provide a link to the original comment (remote storage public directory link to the comment text). so therefore - that domain needs to be able to provide a salmon endpoint as well. it's unclear whether there is any sticky-ness involved with an aggregator endpoint that accepts salmon info for multiple different users/sandboxes.

3.d) the commenters remote storage provider gets contacted about any new acitivity in that blog even though it's not a real aggregator and doesn't care.

-- I didn't find it, but I would assume (hope) there's some way to tell the source that you don't wish to be informed of updates. in which case point 3.c and 3.d are nullified.

If the above summary is somewhat correct, then the main problem is that, there is a complicated set of requirements which need to be in place for the comment application (unhosted comment module) to even work (remoteStorage, sockethub, correct webfinger details for both, salmon endpoints on both the remote storage provider and blog source)... and in the end, the comment is copied anyway, so it looses all value of being 'unhosted' since the end result is the comment lives on the source.

but as i said, i think this is really not that easy. i definitely think we should get email, irc, facebook and twitter working first, and also github and webrtc. Commenting, like user search, is a hard problem to solve. :)

Of course, I never put this above those things, but it's a curiosity, and from what we've discussed so far, it's not that it's difficult, but that the end result is somewhat self-defeating of being 'unhosted'. :/

[silverbucket]

I just want to make it clear that I don't know much about salmon and have only started reading up on it the past few days, so second and third sets of eyes on my assumptions would be very helpful. there are probably aspects i've either misunderstood or missed completely.

On Wed, Feb 6, 2013 at 12:53 PM, Nick Jennings nick@silverbucket.net wrote:

Even though this is not a high priority for sockethub, lets continue to talk this through, if you don't mind. It's a healthy exercise :)

On Wed, Feb 6, 2013 at 3:25 AM, Michiel@unhosted notifications@github.com wrote:

re @silverbucket letting the source know you published a comment is exactly what we need. the user would host the comment, and then send a salmon slap to the website. afaik you cannot send a salmon slap from an unhosted web app, because it needs to be cryptographically signed. so the outgoing slap would have to go through sockethub.

... so the commenter would take on the role of aggregator or secondary publisher in this case. although they don't have a published copy of the source post, they are informing the source that there is a comment for them. this gist makes sense. however, based on my understanding of salmon, there are specific issues with this approach:

1. the protocol of salmon seems to be that it duplicates comments. when an aggregator notifies the source of a comment, it actually sends the comment, to be duplicated on the source. this would, in effect, no longer give the original commenter control over the copy of their comment which now lives in source post.
2. since the commenter takes on the role of aggregater, the salmon protocol defines the responsibility of the source to broadcast to all registered aggregators a copy of a comment whenever it's received. since, in our use case, the aggregator is a singer commenters remote storage location, this doesn't make any sense.
3. the salmon protocol would first need to be implemented in the blog software / http server of the source post, as well as the commentors remote storage provider, before it's of any use to sockethub... specifically:

3.a) the commenting app, which lives on the source, would require the user to log into their remote storage account and their sockethub account - this can be achieved if the useraddress webfinger resource has both their remote storage and sockethub details included. this implies remote storage providers would need to provide sockethub acconts for their users, and sockethub and remote storage become somewhat married. a user could always have their own webfinger resource for their vanity domain ie. nick@silverbucet.net, which specifies their own sockethub instance - however for most users this wont be the case, if all they have done is sign up for a 5apps account.

3.b) the source blog sould need to provide a salmon endpoint, and be able to write to the users remote storage with salmon data.

3.c) the commenters sockethub posts to the source salmon endpoint, they must provide a link to the original comment (remote storage public directory link to the comment text). so therefore - that domain needs to be able to provide a salmon endpoint as well. it's unclear whether there is any sticky-ness involved with an aggregator endpoint that accepts salmon info for multiple different users/sandboxes.

3.d) the commenters remote storage provider gets contacted about any new acitivity in that blog even though it's not a real aggregator and doesn't care.

-- I didn't find it, but I would assume (hope) there's some way to tell the source that you don't wish to be informed of updates. in which case point 3.c and 3.d are nullified.

If the above summary is somewhat correct, then the main problem is that, there is a complicated set of requirements which need to be in place for the comment application (unhosted comment module) to even work (remoteStorage, sockethub, correct webfinger details for both, salmon endpoints on both the remote storage provider and blog source)... and in the end, the comment is copied anyway, so it looses all value of being 'unhosted' since the end result is the comment lives on the source.

but as i said, i think this is really not that easy. i definitely think we should get email, irc, facebook and twitter working first, and also github and webrtc. Commenting, like user search, is a hard problem to solve. :)

Of course, I never put this above those things, but it's a curiosity, and from what we've discussed so far, it's not that it's difficult, but that the end result is somewhat self-defeating of being 'unhosted'. :/

[hugoroy]

When I host a blog, I want to host the comments myself too if I display them directly on the page. What if there is spam, or trolling etc? Yes, that means the person posting a comment does not control entirely how their comment is displayed on the blog, but that's normal.

What if a comment is racist? I may be required under French low to disable that comment.

I think the best way to do unhosted comment is if the blogger's remotestorage hosts the comment. The commenter's remotestorage holds a duplicate of that comment.

That way, I can have an overview of all my comments (even those which were disabled by the blogger) and the blogger keeps control over the comments on their blog.

[xMartin]

I fully agree with @hugoroy. Still, I know this is about adventures so play around with stuff if you feel like it. Don't see a high priority for unhosting comments in general, though. A blog is rather a page than an app and it's great to have comments as static content.

[silverbucket]

The salmon spec does mention the comments posted to the blog to not need to show up immediately, as with any commenting system, there should always be ways to review content before it shows up to the world. I don't think the two things are mutually exclusive (reviewing posts, and giving the commenter control over their comment).

My point is, what does it matter in the end that the process was 'unhosted', why not just post a comment to the blog like people do now? Just to have a copy? Doesn't seem like such a good reason to implement that complex of a system. There should be more to it than that.

On Wed, Feb 6, 2013 at 1:31 PM, Hugo Roy notifications@github.com wrote:

When I host a blog, I want to host the comments myself too if I display them directly on the page. What if there is spam, or trolling etc? Yes, that means the person posting a comment does not control entirely how their comment is displayed on the blog, but that's normal.

What if a comment is racist? I may be required under French low to disable that comment.

I think the best way to do unhosted comment is if the blogger's remotestorage hosts the comment. The commenter's remotestorage holds a duplicate of that comment.

That way, I can have an overview of all my comments (even those which were disabled by the blogger) and the blogger keeps control over the comments on their blog.

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/26#issuecomment-13179767.

[silverbucket]

On Wed, Feb 6, 2013 at 1:41 PM, xMartin notifications@github.com wrote:

I fully agree with @hugoroy https://github.com/hugoroy. Still, I know this is about adventures so play around with stuff if you feel like it. Don't see a high priority for unhosting comments in general, though. A blog is rather a page than an app and it's great to have comments as static content.

Yeah, but you must admit (or, at least the way I see it), a commenting system like disqus is even better than commenting directly to a blog. The original idea (for me) was to create a disqus-ish clone using unhosted technology. Doesn't seem to be possible though.

[silverbucket]

from the salmon website:

The source responds to the salmon with standard HTTP codes - 2xx for OK, 4xx for input problem, 5xx for source / server error. The usual result is for the salmon to be published along with other comments on the source's web page. Note that sources are not obligated to actually publish the salmon -- they may moderate them, spam block them, aggregate or analyze them instead. However, if the source does publish the salmon in a comment feed, it has to maintain certain fields to make the protocol work end-to-end.

http://www.salmon-protocol.org/salmon-protocol-summary

On Wed, Feb 6, 2013 at 1:43 PM, Nick Jennings nick@silverbucket.net wrote:

On Wed, Feb 6, 2013 at 1:41 PM, xMartin notifications@github.com wrote:

I fully agree with @hugoroy. Still, I know this is about adventures so play around with stuff if you feel like it. Don't see a high priority for unhosting comments in general, though. A blog is rather a page than an app and it's great to have comments as static content.

Yeah, but you must admit (or, at least the way I see it), a commenting system like disqus is even better than commenting directly to a blog. The original idea (for me) was to create a disqus-ish clone using unhosted technology. Doesn't seem to be possible though.

[xMartin]

No, I don't agree. Disqus is much worse than blog comments. Blogs are a nice decentralized thing and if I comment somewhere, I just respect and trust the author and willingly give away my content. It then is rendered as static web content so search engines and whatnot have access to it. blog comments are content.

disqus is centralized and neither the comment author nor the blog author have any control. And I really don't see the point why comment would be loaded by scripts rather than being part of the page.

[silverbucket]

On Wed, Feb 6, 2013 at 1:48 PM, xMartin notifications@github.com wrote:

No, I don't agree. Disqus is much worse than blog comments. Blogs are a nice decentralized thing and if I comment somewhere, I just respect and trust the author and willingly give away my content. It then is rendered as static web content so search engines and whatnot have access to it. blog comments are content.

disqus is centralized and neither the comment author nor the blog author have any control. And I really don't see the point why comment would be loaded by scripts rather than being part of the page.

I was referring specifically to the user experience. I think it's more enjoyable, from both a commenters perspective, and also from a blog maintainers perspective.

From a technical side, I agree with what you've said about the centralization, which is why I would like to make an unhosted version, with static caching for search engines. However I'd like to adopt the beneficial aspects of disqus where possible. Some way to say "this is me leaving the comment" and have "this is me" be an ongoing representation of you, not a fleeting snapshot, or out of date record.

I don't like that disqus has the control, but they didn't catch on because the user experience is worse than, or the same as, a normal commenting system. They caught on because they are addressing a need, and that's a cohesive experience, single sign-on, profile & links, ease of use, quicker results for both the user and the poster, accountability, etc.

[xMartin]

I see. Can't say much about that. The negative aspects kept me from exploring the positive ones so far.