Opened 15 years ago
Closed 13 years ago
#138 closed defect (wontfix)
ostatus breaks permissions and vice versa — at Version 9
| Reported by: | Caleb Davis | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | programming | Keywords: | |
| Cc: | Parent Tickets: |
Description (last modified by )
In the quest for ostatus federation + privacy we will come across conflicts of interest between ease of communication and permissions. These will manifest themselves as mutually exclusive design constraints. Now that we have a first draft of the privacy design we can list these conflicts in this issue as we come across them in the wild.
We could close this ticket after all ostatus protocols are evaluated thoroughly for incompatibility with privacy. In the meantime, please try to establish whether your finding is either green - no conflict, yellow - possible/unsure, or red - clear conflict.
Change History (9)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
pubsubhubbub (push) The publisher and the subscriber each have a push server that may or may not be co-located with the users' account hosts. The publisher server is told by the publisher when a new update is available. Subscribers register themselves on the publisher's server for access to individual publisher feeds. Those subscribers to the publisher's feed receive notifications of the update via the subscriber's server. The subscriber's server is handling the user's subscriptions across the web.
http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-specification.html
GREEN - sections 1-8 YELLOW - section 9:
9. Update publication
The publisher server uses PubSubHubbub [push] to notify subscribers of new updates.
If multiple subscribers using the same subscriber server subscribe to the same publisher, the subscriber server SHOULD use the one PubSubHubbub subscription for all of them.
two users on the same subscriber server 'following' the same publisher account SHOULD receive the same content, regardless of publisher's wishes. The keyword SHOULD means we can ignore the rule as long as we understand the consequences. Not sure what those would be yet.
comment:3 by , 15 years ago
The wiki is ready!
I think, the content in here should be migrated there?
Under what page? "Devel/OStatus_vs_Permissions"?
comment:4 by , 15 years ago
We can move conversation there. Although it looks like the OStatus people will be addressing this directly very soon: https://groups.google.com/group/ostatus-discuss/browse_thread/thread/7f15df316d6c14d3
Maybe we don't need to do too much personal research now as they will be doing this already, or we can focus our research on working with them directly?
comment:5 by , 15 years ago
| Status: | New → In Progress |
|---|
I think, the wiki is better for documenting the results, not for actual discussions/converstations. For example the result, that webfinger is no problem and could be implemented right away without any issues.
The bug/issue seems fine for discussions though.
comment:6 by , 15 years ago
The Federated Social Web 2011 conference was last month in Germany, and I did not go. :`(
But, all is not lost! I'm watching some of the presentations tonight, and I was very happy to see this privacy federation workshop - http://d-cent.org/fsw2011/w3c-workshop-33-privacy-on-the-federated-social-web/. There is a speaker addressing OStatus privacy from 26:00 - 30:40.
EDIT: the next speaker (~31:00-39:00) provides the distinction between proactive and reactive privacy controls. He's calling for systems to monitor the flow of personal data through a federated social network, so that, not only can you decide who gets to see your stuff, but you also get to see where your stuff went afterwards. EDIT: AKA DRM for social data
EDIT: at (1:14:24) I stopped for now.
comment:7 by , 15 years ago
julia anaya's post today on the pubsubhubbub list draws attention to a white paper relevant to private push.
thread - http://groups.google.com/group/pubsubhubbub/browse_thread/thread/27a2eaae99f2c584 white paper - http://www.google.com/url?sa=D&q=http://d-cent.org/fsw2011/wp-content/uploads/fsw2011-SMOB-The-best-of-both-worlds.pdf
comment:9 by , 13 years ago
| Component: | → programming |
|---|---|
| Description: | modified (diff) |
| Resolution: | → wontfix |
| Status: | assigned → closed |
We're moving to the pump API and this is irrelevant in that future.

webfinger Either your account is discoverable or not. If my instance is hosted at mediagoblin.cfdv.zzz, member dev_user's URI is something like dev_user@mediagoblin.cfdv.zzz. A query on the URI given a template (http://mediagoblin.cfdv.zzz/?uri=[uri]) provides the appropriate links to dev_user's feeds.
GREEN - webfinger is as private as any email address. http://code.google.com/p/webfinger/wiki/WebFingerProtocol