OStatus 1.5
251 views
Skip to first unread message
Evan Prodromou
Jul 6, 2011, 1:45:29 PM7/6/11
to ostatus
...or 1.1 or 2.0 or NG. At the Federated Social Web summit in Berlin a
few weeks ago, I held an Open Space session about what we'd do for the
next version of OStatus. This is based on about a year's worth of
experience with Identi.ca and StatusNet as well as comments we've had
from implementers so far.
These are the items I noted for a next version:
1. Limited distribution ("privacy"). Currently we use PubSubHubbub for
distributing activities to subscribers. Although PuSH is a really nice
system, the "hub" in the middle makes it hard to limit distribution.
Ideally we'd like to add a layer that allows users to publish
activities that can only be read, or reacted to, by a limited number
of people. For example: only members of a group, only people directly
addressed (for StatusNet, this is "remote DM"), only people on a given
contact list (like Google Circles). There's a lot of work to do here;
I think we'll need to work with others concerned with PuSH.
2. Activity Streams JSON. This has become the "preferred" form of
Activity Streams, so we'd like to favour it in our structure as well.
There are some tricky parts here; I don't believe there's any support
for JSON in Salmon, so we'll need to work with the upstream spec
developers there, too. But I believe we'll move to JSON as a SHOULD
implement and Atom and RSS as a MAY implement.
3. Conversation tracking. One of the big complaints we get about
OStatus on StatusNet and identi.ca is that federation "breaks"
conversational context. That is, if A is subscribed to B, and B
publishes a photo, and C comments on that, A will see B's photo but
not C's comment. One idea here is using Atom threading extensions +
PuSH so that B's photo includes a comments feed, which A's server can
subscribe to, and thus get all activities related to the photo.
However, there doesn't seem to be a similar mechanism in Activity
Streams JSON, which means we'll need to make something up here.
4. Remote site UI. A user from identi.ca who is browsing through
evan.status.net can subscribe to my feed there. We have a mechanism
with Webfinger discovery of a Web endpoint that can be used to
initiate subscription. However, there are lots of things that people
are used to doing to social data on sites they're logged into that
they can't do on remote sites with OStatus: "fave" or "like", "repeat"
or "retweet" or "share", "reply". We'd like to set up a mechanism so
that a user from one service can browse a stream on another service
and interact directly.
These are the main pain points we've hit so far. Is there anything
we're missing here? I'd like to start addressing them to move to a
second version of OStatus, perhaps sometime in the fall.
-Evan
few weeks ago, I held an Open Space session about what we'd do for the
next version of OStatus. This is based on about a year's worth of
experience with Identi.ca and StatusNet as well as comments we've had
from implementers so far.
These are the items I noted for a next version:
1. Limited distribution ("privacy"). Currently we use PubSubHubbub for
distributing activities to subscribers. Although PuSH is a really nice
system, the "hub" in the middle makes it hard to limit distribution.
Ideally we'd like to add a layer that allows users to publish
activities that can only be read, or reacted to, by a limited number
of people. For example: only members of a group, only people directly
addressed (for StatusNet, this is "remote DM"), only people on a given
contact list (like Google Circles). There's a lot of work to do here;
I think we'll need to work with others concerned with PuSH.
2. Activity Streams JSON. This has become the "preferred" form of
Activity Streams, so we'd like to favour it in our structure as well.
There are some tricky parts here; I don't believe there's any support
for JSON in Salmon, so we'll need to work with the upstream spec
developers there, too. But I believe we'll move to JSON as a SHOULD
implement and Atom and RSS as a MAY implement.
3. Conversation tracking. One of the big complaints we get about
OStatus on StatusNet and identi.ca is that federation "breaks"
conversational context. That is, if A is subscribed to B, and B
publishes a photo, and C comments on that, A will see B's photo but
not C's comment. One idea here is using Atom threading extensions +
PuSH so that B's photo includes a comments feed, which A's server can
subscribe to, and thus get all activities related to the photo.
However, there doesn't seem to be a similar mechanism in Activity
Streams JSON, which means we'll need to make something up here.
4. Remote site UI. A user from identi.ca who is browsing through
evan.status.net can subscribe to my feed there. We have a mechanism
with Webfinger discovery of a Web endpoint that can be used to
initiate subscription. However, there are lots of things that people
are used to doing to social data on sites they're logged into that
they can't do on remote sites with OStatus: "fave" or "like", "repeat"
or "retweet" or "share", "reply". We'd like to set up a mechanism so
that a user from one service can browse a stream on another service
and interact directly.
These are the main pain points we've hit so far. Is there anything
we're missing here? I'd like to start addressing them to move to a
second version of OStatus, perhaps sometime in the fall.
-Evan
Brion Vibber
Jul 6, 2011, 2:24:37 PM7/6/11
to ostatus...@googlegroups.com
On Wed, Jul 6, 2011 at 10:45 AM, Evan Prodromou <evan.pr...@gmail.com> wrote:
3. Conversation tracking. One of the big complaints we get about
OStatus on StatusNet and identi.ca is that federation "breaks"
conversational context. That is, if A is subscribed to B, and B
publishes a photo, and C comments on that, A will see B's photo but
not C's comment. One idea here is using Atom threading extensions +
PuSH so that B's photo includes a comments feed, which A's server can
subscribe to, and thus get all activities related to the photo.
However, there doesn't seem to be a similar mechanism in Activity
Streams JSON, which means we'll need to make something up here.
I think there's basically two parts of this:
* ensuring that new messages on a thread get posted out to relevant listeners on the thread
* ensuring that old messages on a thread are accessible if you become a listener on the thread partway through
The latter is possibly related to 4) -- part of the problem with federated threading is what to do if you weren't a recipient of messages in the thread until partway through. If we have a consistent way to go back and fetch the previous parts of the conversation when a host has one of their users added to it the first time, this may be much simpler.
4. Remote site UI. A user from identi.ca who is browsing through
evan.status.net can subscribe to my feed there. We have a mechanism
with Webfinger discovery of a Web endpoint that can be used to
initiate subscription. However, there are lots of things that people
are used to doing to social data on sites they're logged into that
they can't do on remote sites with OStatus: "fave" or "like", "repeat"
or "retweet" or "share", "reply". We'd like to set up a mechanism so
that a user from one service can browse a stream on another service
and interact directly.
I really like this -- dealing with things on a remote web site was definitely always one of the biggest difficulties in federation without explicit browser support (mailto: links being a primitive example) or centralization (which leads to the nascar problem for multiple services).
This should also be something that can be built up from the same information we already have to make available for discovery -- add paging, search, and identity confirmation layers and you can make it more flexible, but if all we've got is a single public RSS/Atom feed and some static info we can still show that and make those entries available for view/fave/repeat/etc as if they had previously come in.
These are the main pain points we've hit so far. Is there anything
we're missing here? I'd like to start addressing them to move to a
second version of OStatus, perhaps sometime in the fall.
I think there could be a benefit to explicit notions of account transference.
Most of today's social networks aim for lock-in and make it very difficult to move your identity to another service -- even if you can transfer your posts and your subscriptions, we don't have a good way to make sure that people who have subscribed or friended end up following your new identity. OStatus 1 is also fairly sensitive to URL changes; a web site that changes its domain name or URL structure can easily break the PuSH subscriptions if it's not very careful. Maintaining redirects for old URLs should allow keeping the old URIs intact without breaking anything, but in practice I know we had some difficulties with this at StatusNet.
To make it a little easier on site re-orgs, and a *lot* easier on individuals having the freedom to move their accounts from service to service, we could consider a way to announce to all subscribers that an account is moving, and that their subscriptions should be automatically updated to a new location that's considered to be part of the same trusted identity.
Thus I could hop from, say, bri...@identi.ca to a self-hosted bri...@brionv.com (or vice-versa!) without having to beg everyone in my social graph to update their friends list.
-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
Christopher Allan Webber
Jul 6, 2011, 2:26:23 PM7/6/11
to ostatus...@googlegroups.com
This is extremely exciting. We'll be shortly moving on to federation
with OStatus and etc with MediaGoblin. I know that several members of
our team have wanted to work on private media sharing stuff and I've
been concerned that working on this may complicate federation.
with OStatus and etc with MediaGoblin. I know that several members of
our team have wanted to work on private media sharing stuff and I've
been concerned that working on this may complicate federation.
I'd be interested to know if the privacy considerations here will extend
beyond just the textual and metadata exchange and possibly into media
exchange also. Presuming that I have an image that's on my server that
only my friends can see, and presuming I *do* have some way on my server
to restrict the publication of that image (perhaps via the X-SendFile
header collaboration between the application and nginx/apache), I'd be
interested to know if there's some way my server can validate whether or
not you're authorized to view this photo. (OpenID?)
I'm not sure that's out of scope of OStatus 1.5, but it's something I'm
very interested in.
Regardless, looks exciting & promising! I'm quite enthused.
- cwebb
Evan Prodromou <evan.pr...@gmail.com> writes:
Michiel de Jong
Jul 6, 2011, 2:39:45 PM7/6/11
to ostatus...@googlegroups.com
Any chance of mentioning CORS in the spec?
As http://enable-cors.org/ explains, public and cookie-agnostic data should now be served with CORS headers. That includes Webfinger. This is already supported by the following projects:
- Unhosted
- Diaspora*
- WordPress-plugin
- others underway
I think this is important as html5 apps will gradually become more important, so it would be nice if the OStatus spec could at least mention it.
Many thanks!
Michiel
julia.anaya
Jul 6, 2011, 3:40:04 PM7/6/11
to ostatus...@googlegroups.com
On 06/07/11 18:45, Evan Prodromou wrote:
> ...or 1.1 or 2.0 or NG. At the Federated Social Web summit in Berlin a
> few weeks ago, I held an Open Space session about what we'd do for the
> next version of OStatus. This is based on about a year's worth of
> experience with Identi.ca and StatusNet as well as comments we've had
> from implementers so far.
>
> These are the items I noted for a next version:
>
> 1. Limited distribution ("privacy"). Currently we use PubSubHubbub for
> distributing activities to subscribers. Although PuSH is a really nice
> system, the "hub" in the middle makes it hard to limit distribution.
> Ideally we'd like to add a layer that allows users to publish
> activities that can only be read, or reacted to, by a limited number
> of people. For example: only members of a group, only people directly
> addressed (for StatusNet, this is "remote DM"), only people on a given
> contact list (like Google Circles). There's a lot of work to do here;
> I think we'll need to work with others concerned with PuSH.
>
> ...or 1.1 or 2.0 or NG. At the Federated Social Web summit in Berlin a
> few weeks ago, I held an Open Space session about what we'd do for the
> next version of OStatus. This is based on about a year's worth of
> experience with Identi.ca and StatusNet as well as comments we've had
> from implementers so far.
>
> These are the items I noted for a next version:
>
> 1. Limited distribution ("privacy"). Currently we use PubSubHubbub for
> distributing activities to subscribers. Although PuSH is a really nice
> system, the "hub" in the middle makes it hard to limit distribution.
> Ideally we'd like to add a layer that allows users to publish
> activities that can only be read, or reacted to, by a limited number
> of people. For example: only members of a group, only people directly
> addressed (for StatusNet, this is "remote DM"), only people on a given
> contact list (like Google Circles). There's a lot of work to do here;
> I think we'll need to work with others concerned with PuSH.
>
Maybe "Semantic hub" we are implementing and was presented in the
conference could solve part of the privacy. [1]
The main advantage of our implementation is that users have not to
create static/closed groups.
What the clients (subscriber or publisher) should implement and differ
from the current (Google) PuSH implementation:
1. subscribers must have a private FOAF profile where the user interests
and relationships with other people are stored (this can be extended but
we are using only this user data at the moment).
The private FOAF profile can be generated through a web form and
converted to FOAF. We use a triple store but it's not needed.
2. when a subscriber ask for a subscription to the hub, the hub will ask
the subscriber its private FOAF profile. The subscriber will grant
access to its profile the hub authenticating it with WebID, which means
that the subscriber asks the hub a certificate, dereferences the public
WebID URI in it and checks that the rsa key in both is the same.
3. the publishers must have what we call "Privacy Preferences". This are
created through a simple form where the user choose the hashtag that a
post must have to apply that preference, and the interest or/and the
relationship with the publisher that the subscriber must have to receive
the post.
4. when publisher creates a new post, the privacy preferences matching
the hashtag are included in the post item feed.
5. apart of the privacy preferences included in the item feed, the post
should be converted to SIOC and stored also in the item feed. Again we
use a triple store here, but the post in SIOC format can be generated
dynamically and included in the RSS that in our case is a file.
These changes can be implemented in a transparent way to the user that
doesn't need to know anything about Semantic Web, and the logic to
decide which subscribers are receiving the posts is the hub responsibility.
I think that some parts of the SMOB code (PHP) can even be reused in
status.net.
We still don't have an online demo, but will have it soon. And the
implementation will be ready in a month (for production maybe add
another month).
Julia.
[1]
http://d-cent.org/fsw2011/wp-content/uploads/fsw2011-SMOB-The-best-of-both-worlds.pdf
Singpolyma
Jul 6, 2011, 6:53:48 PM7/6/11
to ostatus
On Jul 6, 12:45 pm, Evan Prodromou <evan.prodro...@gmail.com> wrote:
> 1. Limited distribution ("privacy"). Currently we use PubSubHubbub for
> distributing activities to subscribers. Although PuSH is a really nice
> system, the "hub" in the middle makes it hard to limit distribution.
> Ideally we'd like to add a layer that allows users to publish
> activities that can only be read, or reacted to, by a limited number
> of people
Unless you're doing end2end encryption (which doesn't really fit the
> 1. Limited distribution ("privacy"). Currently we use PubSubHubbub for
> distributing activities to subscribers. Although PuSH is a really nice
> system, the "hub" in the middle makes it hard to limit distribution.
> Ideally we'd like to add a layer that allows users to publish
> activities that can only be read, or reacted to, by a limited number
> of people
mode much) you have to trust the servers anyway. So if you control
the hub and the hub knows about the distribution requirements, you can
just push to the servers that matter. Though you need a way to markup
"only show to X".
> 2. Activity Streams JSON. This has become the "preferred" form of
> Activity Streams, so we'd like to favour it in our structure as well.
> There are some tricky parts here; I don't believe there's any support
> for JSON in Salmon, so we'll need to work with the upstream spec
> developers there, too. But I believe we'll move to JSON as a SHOULD
> implement and Atom and RSS as a MAY implement.
good at representing extensible feeds like we're dealing with here.
Already you've identified that Salmon may need to be "ported". There
will be more of that. The other, more important, reason this is a
*terrible* idea is compatibility. The whole benefit of PSHB/OStatus/
ActivityStreams is that it's just layering data on top of feeds people
are publishing anyway *and* clients who don't know about (or don't
know about all) the new techs you are layering on top *still work just
fine*. This is a *very important feature* and is the difference
between "you should OStatus enable your feed" and "you should
implement this whole new protocol just for us".
> 3. One idea here is using Atom threading extensions +
> PuSH so that B's photo includes a comments feed, which A's server can
> subscribe to, and thus get all activities related to the photo.
> However, there doesn't seem to be a similar mechanism in Activity
> Streams JSON, which means we'll need to make something up here.
This is a very good idea. This issue you're identifying is just the
> subscribe to, and thus get all activities related to the photo.
> However, there doesn't seem to be a similar mechanism in Activity
> Streams JSON, which means we'll need to make something up here.
first of many you will run into if you try to replace the rich,
existing ecosystem of Atom layers with castrated AS-only JSON.
> 4. Remote site UI. A user from identi.ca who is browsing through
> evan.status.net can subscribe to my feed there. We have a mechanism
> with Webfinger discovery of a Web endpoint that can be used to
> initiate subscription. However, there are lots of things that people
> are used to doing to social data on sites they're logged into that
> they can't do on remote sites with OStatus: "fave" or "like", "repeat"
> or "retweet" or "share", "reply".
similar way?
Max Ogden
Jul 6, 2011, 7:02:04 PM7/6/11
to ostatus...@googlegroups.com
If you want so called "modern javascript" developers to pay attention to OStatus then JSON is a smarter strategic decision
eschnou
Jul 7, 2011, 9:50:13 AM7/7/11
to ostatus...@googlegroups.com
Great to see activity on this !
4. Remote site UI. A user from identi.ca who is browsing through
evan.status.net can subscribe to my feed there. We have a mechanism
with Webfinger discovery of a Web endpoint that can be used to
initiate subscription. However, there are lots of things that people
are used to doing to social data on sites they're logged into that
they can't do on remote sites with OStatus: "fave" or "like", "repeat"
or "retweet" or "share", "reply". We'd like to set up a mechanism so
that a user from one service can browse a stream on another service
and interact directly.
Another approach would be to make easier to build a service that enable a user to browse and interact with remote users content without changing context. E.g. If I'm on status.net, why can't I lookup esc...@domain.com profiles and activities in the statusnet UI ? I could reply/like/etc from that same UI. No need for me to navigate to eschnou's domain (and having to authenticate there again for example).
These are the main pain points we've hit so far. Is there anything
we're missing here? I'd like to start addressing them to move to a
second version of OStatus, perhaps sometime in the fall.
Fixing Salmon. I never managed to interop properly with status.net over salmon, and I think I'm not the only one. However cross-domain messaging is fundamental to full federation. There are too many 'federated' projects out there (mine included) which support OStatus except Salmon. That's a pity.
I always found it strange to have one method of message & entity authentication in PuSH and another one in Salmon. Why not have a common API fro cross domain messaging and then build things like PubSub/messages/etc... on top of it ? There is existing work on which this could be built, like Blaine's "Private Webhooks"' and the "domain federation spec" from Martin Atkins.
Looking forward to the next steps,
Cheers,
Laurent
Singpolyma
Jul 7, 2011, 10:05:15 AM7/7/11
to ostatus
On Jul 6, 7:02 pm, Max Ogden <m...@maxogden.com> wrote:
> If you want so called "modern javascript" developers to pay attention to
> OStatus then JSON is a smarter strategic decision
"We should do it because it's cool" is not a very compelling
> If you want so called "modern javascript" developers to pay attention to
> OStatus then JSON is a smarter strategic decision
counterargument to "we should not do it because it breaks
compatibility with huge amounts of the web".
I'm not saying you can't use JSON for things, I'm saying Atom should
remain the primary encoding.
Danny Ayers
Jul 7, 2011, 11:39:21 AM7/7/11
to ostatus...@googlegroups.com
I put a lot of time into Atom, I believed (and still believe) it's a
lot better than random tag soup RSS.
Now JSON appears to be a lot easier to deal with, but it does have a
hole that Atom didn't have. I'll use the swear-word in moment, after
saying that Atom is very Web-friendly because it's linky.
The swear-word is namespaces - ok, now forget that. But JSON seems
poor when it comes to having URLs, it tends to have all the worst
characteristic of SOAP, that we all hoped we'd moved beyond.
I've not thought through how to express this properly, but I reckon to
go forwards, we want to cherry-pick the best bits of the technologies
out there. If we want to use the Web, URLs must be in there from day
one.
Cherry-picking again, I think the data model of RDF is the closest
that fits the Web environment, and ... oh dear, now the O Word - the
ontologies and vocabulary management bits of the semantic web are
worth taking on board. Cherries.
But cherries on the pie, that I think is something learnt - make the
pie first, but do it intelligently with respect to all the background
material. Making new stuff is fun, but long-term it's doomed.
Cheers,
Danny.
Matt Katz
Jul 7, 2011, 12:52:01 PM7/7/11
to ostatus...@googlegroups.com
I choose json over any xml every chance I get, but I find the pro xml argument much more compelling here. Ostatus as stack of other protocols is a good design, and out wouldn't do us much good to support xml AND json.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Matthias Pfefferle
Jul 7, 2011, 1:27:38 PM7/7/11
to ostatus
I also prefer Atom/RSS, not only because of the technical aspects and
the better extensibility, but because of the compatibility to the
"normal" (not federated/indie) web. Up to now status.net lets you
follow every site which uses a atom/rss-feed (for example
wordpress.org, posterous, tumblr, twitter, ....) without forcing them
to implement anything and it allows plattform owners to implement
OStatus step by step.
On 7 Jul., 18:52, Matt Katz <matthew.k...@morelightmorelight.com>
wrote:
the better extensibility, but because of the compatibility to the
"normal" (not federated/indie) web. Up to now status.net lets you
follow every site which uses a atom/rss-feed (for example
wordpress.org, posterous, tumblr, twitter, ....) without forcing them
to implement anything and it allows plattform owners to implement
OStatus step by step.
On 7 Jul., 18:52, Matt Katz <matthew.k...@morelightmorelight.com>
wrote:
> I choose json over any xml every chance I get, but I find the pro xml argument much more compelling here. Ostatus as stack of other protocols is a good design, and out wouldn't do us much good to support xml AND json.
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> Danny Ayers <danny.ay...@gmail.com> wrote:
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
Laurent-Walter Goix
Jul 8, 2011, 5:16:27 AM7/8/11
to ostatus
From an industry perspective it may be worth thinking at the user
concerns first, and thus at those features that social networks in
general, and federation in particular, are related to privacy etc.
As such I definitely agree at supporting privacy levels to restrict
the visibility of activities and introduce 'private messaging' (incl.
1-to-many). I also would emphasize related features such as deletion
(informing other users I deleted some content/activity, read Atom
Tombstones or similar), and portability of user history as already
mentioned in this thread (such as wordpress does import/export or
google takeout): with federation we should expect users to rapidly
migrate across SNs.
Regarding remote site ui, are you thinking at something similar to
oexchange, enhanced to support additional features besides sharing a
link?
As per some other optimizations, say json/atom, I would see them as
secondary as more related to developers' concerns. In particular i
also believe that Atom between federated servers may still be much
more appropriate than json (which I understand is better towards web
clients): as long as the data model is identical (activity streams) I
don't see major issues with this and it doesn't introduce any novel
functionality.
As a side question, may i ask about your intentions where to develop
this new spec? Do you envision to maintain the same process than for
current version or address it under w3c fsw?
concerns first, and thus at those features that social networks in
general, and federation in particular, are related to privacy etc.
As such I definitely agree at supporting privacy levels to restrict
the visibility of activities and introduce 'private messaging' (incl.
1-to-many). I also would emphasize related features such as deletion
(informing other users I deleted some content/activity, read Atom
Tombstones or similar), and portability of user history as already
mentioned in this thread (such as wordpress does import/export or
google takeout): with federation we should expect users to rapidly
migrate across SNs.
Regarding remote site ui, are you thinking at something similar to
oexchange, enhanced to support additional features besides sharing a
link?
As per some other optimizations, say json/atom, I would see them as
secondary as more related to developers' concerns. In particular i
also believe that Atom between federated servers may still be much
more appropriate than json (which I understand is better towards web
clients): as long as the data model is identical (activity streams) I
don't see major issues with this and it doesn't introduce any novel
functionality.
As a side question, may i ask about your intentions where to develop
this new spec? Do you envision to maintain the same process than for
current version or address it under w3c fsw?
paulbo...@gmail.com
Jul 8, 2011, 9:58:00 AM7/8/11
to ostatus...@googlegroups.com, Matthias Pfefferle
Matt Katz
Jul 8, 2011, 12:14:14 PM7/8/11
to ostatus...@googlegroups.com
Regarding remote site operations, perhaps some tweak of oembed is useful. Let them define their remote ops.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Pelle Wessman
Jul 10, 2011, 2:18:49 AM7/10/11
to ostatus...@googlegroups.com
There's a slight problem here though - OStatus is a stack of other protocols but Atom isn't one of them - it's ActivityStreams and that community has already moved from having Atom as their primary data format to having JSON as it.
If we want to keep in line with the protocols that OStatus is made up from - which is one of the great advantages of OStatus - then we should probably move to have the same primary data format as the ActivityStreams community.
Having JSON as the primary format in no way means that people can't support Atom as well - the spec should encourage sites to support Atom - but we should only demand a single data format and that should probably be the same format as promoted by the ActivityStreams community.
/ Pelle
If we want to keep in line with the protocols that OStatus is made up from - which is one of the great advantages of OStatus - then we should probably move to have the same primary data format as the ActivityStreams community.
Having JSON as the primary format in no way means that people can't support Atom as well - the spec should encourage sites to support Atom - but we should only demand a single data format and that should probably be the same format as promoted by the ActivityStreams community.
/ Pelle
Pelle Wessman
Jul 10, 2011, 2:30:49 AM7/10/11
to ostatus...@googlegroups.com
Regarding main points missing - I would like the spec to address the three different kind of OStatus participants: Providers, Aggregators and Clients. Describe each one of them and what's expected from them to be "OStatus compliant". If I remember correctly the current specification is written from the perspective of a full social network that contains all parts.
To clarify the kinds of participants as I see them:
A publisher publishes OStatus activities - this might be almost any site - Foursquare, eBay etc.
An aggregator gathers and republishes activities under a unified canonical OStatus identity - this creates the profile most people are likely to follow.
A client only consumes OStatus activities from around the web and publishes none - it's almost like a Google Reader for social networks.
/ Pelle Wessman
To clarify the kinds of participants as I see them:
A publisher publishes OStatus activities - this might be almost any site - Foursquare, eBay etc.
An aggregator gathers and republishes activities under a unified canonical OStatus identity - this creates the profile most people are likely to follow.
A client only consumes OStatus activities from around the web and publishes none - it's almost like a Google Reader for social networks.
/ Pelle Wessman
Matthias Pfefferle
Jul 10, 2011, 4:40:10 AM7/10/11
to ostatus
This shouldn't be a discussion about "what is technically the best
standard to use" it should be more a discussion about "what formats
are yet used and wide spreaded to make the ostatus implementation as
simple as possible".
[quote]ActivityStreams and that community has already moved from
having Atom as their primary data format to having JSON as it.[/quote]
This is a valid point, but the consequence is not inevitably switching
to JSON, we could change the Spec to use Feeds as main fromat and add
AS as a "nice to have" (and the atom-extension is still part of the
spec and released as final version: http://activitystrea.ms/specs/atom/1.0/)!
Switching the format causes a lot of problems:
* talking to the spec-authors to add json instead of feeds
(pubsubhubbub, salmon, ...) or define new specs to solve these
problems (not good)
* talking to pubsubhubbub-hubs to support json
* talking to services to implement the AS-JSON format
* it would drop backwards compatibility to OStatus 1.0
Implementing OStatus should be as simple as possible, thats why the
spec should fokus on standards which are highly adopted and wide
spreaded.
A simple implementation could be:
* Profile URL for discovery
** rel-alternet for feeds
** author-meta-tag for author name
** pavatar for avatar
** hCard/schema.org for profile informations
* feed for posts/notes
** pubsubhubub is a nice to have
* comment-feed
** pubsubhubub is a nice to have
That would make nearly every blogging plattform (wordpress.com,
wordpress.orf, blogger, tumblr, posterous, ...) a valid OStatus-
Profider without doing anything!
Matthias Pfefferle
On Jul 10, 8:30 am, Pelle Wessman <voxpe...@gmail.com> wrote:
> Regarding main points missing - I would like the spec to address the three
> different kind of OStatus participants: Providers, Aggregators and Clients.
> Describe each one of them and what's expected from them to be "OStatus
> compliant". If I remember correctly the current specification is written
> from the perspective of a full social network that contains all parts.
>
> To clarify the kinds of participants as I see them:
>
> A *publisher* publishes OStatus activities - this might be almost any site -
> Foursquare, eBay etc.
> An *aggregator *gathers and republishes activities under a unified canonical
standard to use" it should be more a discussion about "what formats
are yet used and wide spreaded to make the ostatus implementation as
simple as possible".
[quote]ActivityStreams and that community has already moved from
having Atom as their primary data format to having JSON as it.[/quote]
This is a valid point, but the consequence is not inevitably switching
to JSON, we could change the Spec to use Feeds as main fromat and add
AS as a "nice to have" (and the atom-extension is still part of the
spec and released as final version: http://activitystrea.ms/specs/atom/1.0/)!
Switching the format causes a lot of problems:
* talking to the spec-authors to add json instead of feeds
(pubsubhubbub, salmon, ...) or define new specs to solve these
problems (not good)
* talking to pubsubhubbub-hubs to support json
* talking to services to implement the AS-JSON format
* it would drop backwards compatibility to OStatus 1.0
Implementing OStatus should be as simple as possible, thats why the
spec should fokus on standards which are highly adopted and wide
spreaded.
A simple implementation could be:
* Profile URL for discovery
** rel-alternet for feeds
** author-meta-tag for author name
** pavatar for avatar
** hCard/schema.org for profile informations
* feed for posts/notes
** pubsubhubub is a nice to have
* comment-feed
** pubsubhubub is a nice to have
That would make nearly every blogging plattform (wordpress.com,
wordpress.orf, blogger, tumblr, posterous, ...) a valid OStatus-
Profider without doing anything!
Matthias Pfefferle
On Jul 10, 8:30 am, Pelle Wessman <voxpe...@gmail.com> wrote:
> Regarding main points missing - I would like the spec to address the three
> different kind of OStatus participants: Providers, Aggregators and Clients.
> Describe each one of them and what's expected from them to be "OStatus
> compliant". If I remember correctly the current specification is written
> from the perspective of a full social network that contains all parts.
>
> To clarify the kinds of participants as I see them:
>
> Foursquare, eBay etc.
> An *aggregator *gathers and republishes activities under a unified canonical
> OStatus identity - this creates the profile most people are likely to
> follow.
> A *client *only consumes OStatus activities from around the web and
> follow.
Astro
Jul 15, 2011, 11:35:50 AM7/15/11
to ostatus...@googlegroups.com
Hi,
seeing JSON coming up really hurts. The argument "all the cool kids are
doing it" is a rather weak one. Implementors do not want to burden with
two fundamentally different data formats, and ATOM is in place
everywhere anyway. Therefore it must be implemented by anyone who aims
for compatibility -- the exact reason for OStatus in the first place.
I'd rather see XRD/LRDD replaced by a somewhat more lightweight format,
instead of discarding the rich metadata we put into ATOM.
eschnou wrote:
> Fixing Salmon. I never managed to interop properly with status.net over
> salmon, and I think I'm not the only one. However cross-domain messaging is
> fundamental to full federation. There are too many 'federated' projects out
> there (mine included) which support OStatus except Salmon. That's a pity.
Having worked on your implementation, node-ostatus, I think Salmon is
nice in general. Only that Magic Signature thing seems to come from the
fringes; it was not possible to make it compatible to a StatusNet
instance in terms of signing and verification. I wish John Panzer had
used any widespread protocol already implemented by eg. OpenSSL or
GnuPG.
> I always found it strange to have one method of message & entity
> authentication in PuSH and another one in Salmon. Why not have a common API
> fro cross domain messaging and then build things like PubSub/messages/etc...
> on top of it ? [...]
Both protocols are tailored to fit their niche. For PuSH it's
verification of subscribers and hubs in a URL-based world. For Salmon
it's simple messaging with signature-based verification.
Astro
Evan Prodromou
Jul 15, 2011, 12:28:51 PM7/15/11
to ostatus...@googlegroups.com
On Wed, Jul 6, 2011 at 6:53 PM, Singpolyma <singp...@singpolyma.net> wrote:
On Jul 6, 12:45 pm, Evan Prodromou <evan.prodro...@gmail.com> wrote:
> 1. Limited distribution ("privacy"). Currently we use PubSubHubbub for
> distributing activities to subscribers. Although PuSH is a really nice
> system, the "hub" in the middle makes it hard to limit distribution.
Unless you're doing end2end encryption (which doesn't really fit the
mode much) you have to trust the servers anyway. So if you control
the hub and the hub knows about the distribution requirements, you can
just push to the servers that matter. Though you need a way to markup
"only show to X".
Yes. Right now, the hub is unaware of distribution requirements. We need a way to say, "Send only to people who are members of this group" or "send only to the following people".
> 4. Remote site UI. A user from identi.ca who is browsing through
> evan.status.net can subscribe to my feed there. We have a mechanism
> with Webfinger discovery of a Web endpoint that can be used to
> initiate subscription. However, there are lots of things that people
> are used to doing to social data on sites they're logged into that
> they can't do on remote sites with OStatus: "fave" or "like", "repeat"
> or "retweet" or "share", "reply".
Hmm, this is an interesting problem. I expect it can be solved in a
similar way?
I think so. There's already OExchange for "sharing a bookmark":
http://www.oexchange.org/
Describing what the verbs are, how you can discover which verbs an account supports, and so on is a bit of work.
-Evan
Evan Prodromou
Jul 15, 2011, 12:31:10 PM7/15/11
to ostatus...@googlegroups.com
On Wed, Jul 6, 2011 at 7:02 PM, Max Ogden <m...@maxogden.com> wrote:
If you want so called "modern javascript" developers to pay attention to OStatus then JSON is a smarter strategic decision
I have to agree.
I'm not excited about re-tooling from Atom to JSON, and supporting multiple serializations for Activity Streams, but I'm not sure that ignoring Activity Streams JSON is an option.
I also think we'd have to have a really good reason to favour the "backup" serialization over the "preferred" serialization.
Diana Cheng
Jul 21, 2011, 7:18:55 AM7/21/11
to ostatus...@googlegroups.com
Just to keep the ball rolling:
On 15 July 2011 18:28, Evan Prodromou <evan.pr...@gmail.com> wrote:
On Wed, Jul 6, 2011 at 6:53 PM, Singpolyma <singp...@singpolyma.net> wrote:
On Jul 6, 12:45 pm, Evan Prodromou <evan.prodro...@gmail.com> wrote:
> 1. Limited distribution ("privacy"). Currently we use PubSubHubbub for
> distributing activities to subscribers. Although PuSH is a really nice
> system, the "hub" in the middle makes it hard to limit distribution.Unless you're doing end2end encryption (which doesn't really fit the
mode much) you have to trust the servers anyway. So if you control
the hub and the hub knows about the distribution requirements, you can
just push to the servers that matter. Though you need a way to markup
"only show to X".
Yes. Right now, the hub is unaware of distribution requirements. We need a way to say, "Send only to people who are members of this group" or "send only to the following people".
This was done in OneSocialWeb by adding a new namespace, and extending the ActivityStreams payload to specify rules for the visibility of a given post towards specific groups (your "home server" to which you send the post is aware of your groups and will processes these rules and distribute accordingly). How can this be done for the hubs, especially taking into account that ostatus plans to move away from an extensible format to JSON? What about interop with XMPP-based systems?
Regards,
Diana.
Nils D.
Jul 22, 2011, 7:04:33 AM7/22/11
to ostatus
I agree - JSON is nice for APIs etc., but as part of a stack of
protocols
an extensible underlying format should be prefered.
Adding new threading functionalities to AS JSON or extending Salmon
and PuSH
for JSON events, dealing with XMPP interop ... seems to be harder than
continuing using Atom and extending Atom with namespaced features.
(But I wouldn't mind recommending JRD over XRD, as I expect it to
become
an API similar to SWD in the future.
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00)
Regarding Privacy/Security:
Maybe the Diaspora* team could recommend its crypto-layer as an
optional layer
for secure data transfer. As far as I know, it's an encrypted Magic
Envelope.
I would prefer explicit data encryption over transfer encryption (with
SSL),
because then it's up to the user to store the data encrypted or
decrypted.
Having an avatar standard as part of OStatus would be great, however
Pavatar seems too limited to be acceptable for the moment.
It needs at least XRD/Webfinger support and an optional recommendation
for a
resizing API like Gravatar.
In addition, I would like to have a reciprocity confirmation protocol,
to support symmetric relations (i.e., to allow for "friend"
relationships as well as for "follower" relationships).
This could be part of the remote site UI - so if user Alice states to
be friend with Bob,
user Carol can check automatically if Bob also states that he is a
friend of Alice.
With the PortableContacts API this is already possible*,
but if I understand OStatus 1.0 correctly,
it doesn't say a service has to implement the PoCo API to be OStatus
compliant
(which is a good thing).
A simple protocol for reciprocity confirmation would be great and an
important
feature for symmetric decentralized social networks.
* I think with something like
http://alice.example.com/poco/@me/acct:b...@example.com?filterBy=connected&filterOp=present
...
I did'nt test it.
Well - and this assumes that the PoCo implementation uses Webfinger-
Accts as user IDs,
which is not really common.)
protocols
an extensible underlying format should be prefered.
Adding new threading functionalities to AS JSON or extending Salmon
and PuSH
for JSON events, dealing with XMPP interop ... seems to be harder than
continuing using Atom and extending Atom with namespaced features.
(But I wouldn't mind recommending JRD over XRD, as I expect it to
become
an API similar to SWD in the future.
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00)
Regarding Privacy/Security:
Maybe the Diaspora* team could recommend its crypto-layer as an
optional layer
for secure data transfer. As far as I know, it's an encrypted Magic
Envelope.
I would prefer explicit data encryption over transfer encryption (with
SSL),
because then it's up to the user to store the data encrypted or
decrypted.
Having an avatar standard as part of OStatus would be great, however
Pavatar seems too limited to be acceptable for the moment.
It needs at least XRD/Webfinger support and an optional recommendation
for a
resizing API like Gravatar.
In addition, I would like to have a reciprocity confirmation protocol,
to support symmetric relations (i.e., to allow for "friend"
relationships as well as for "follower" relationships).
This could be part of the remote site UI - so if user Alice states to
be friend with Bob,
user Carol can check automatically if Bob also states that he is a
friend of Alice.
With the PortableContacts API this is already possible*,
but if I understand OStatus 1.0 correctly,
it doesn't say a service has to implement the PoCo API to be OStatus
compliant
(which is a good thing).
A simple protocol for reciprocity confirmation would be great and an
important
feature for symmetric decentralized social networks.
* I think with something like
http://alice.example.com/poco/@me/acct:b...@example.com?filterBy=connected&filterOp=present
...
I did'nt test it.
Well - and this assumes that the PoCo implementation uses Webfinger-
Accts as user IDs,
which is not really common.)
Reply all
Reply to author
Forward
0 new messages