This is a post I sent to SWICG about the 1 unfinished item in the working group, the Social API. I think it’s a missing piece of the puzzle.
Hi All
It’s truly encouraging to witness the renewed momentum in our group. As we
are aware, during the working group’s tenure, there were three REC track
deliverables outlined in the charter [1]
Social Data Syntax
Social API
Federation Protocol
While the first and third deliverables were thoroughly addressed, I believe
the accomplishment of the second - the Social API - could benefit from
further clarity.
Full text:
Social API
A document that defines a specification for a client-side API that lets
developers embed and format third party information such as social status
updates inside Web applications. One input to this deliverable is the
OpenSocial 2.5.1 Activity Streams and Embedded Experiences APIs Member
Submission.
This was intended as a client-side API allowing developers to integrate and
format third-party information, such as social status updates, into web
applications. Its groundwork was the OpenSocial 2.5.1 Activity Streams and
Embedded Experiences APIs [2]
Recently, Rabble brought up the oembed protocol [3], which, despite being a
significant effort and somewhat dated now, I believe still holds relevance
and could be revitalized for current use. Considering it was a REC Track
Deliverable in the SWWG, it could be an excellent foundation for new
chartered work.
A lot of work has gone into this too, with SolidOS [4]. With modern
tooling, I’m optimistic that we can make this task much more achievable
today. If there’s interest from the team, I would be more than willing to
contribute to this effort. I envision a few use cases and areas where this
could deliver value, particularly with solid and nostr, which heavily
depend on client-side apps.
am i missing something here? i’m not sure what @melvincarvalho thinks a “social api” should look like in practice or what is currently missing, but i’m equally unsure why @eprodrom is pointing to AP C2S and Micropub as anything more than a way to publish activities (via AP and AS2) or entries (via Micropub and the Indieweb) to your web profile or web site (or to send notifications to other actors via AP). surely there’s more to this concept?
it seems to me like the purview of the Social WG was largely limited to publishing use-cases, so i assume this is what @melvincarvalho is concerned about. i am making this statement based on the following pages:
particularly, it seems that because publishing was a large component of the majority of the patterns, this bled into the requirements being basically just pub/sub/read/notify. which is a good start, but maybe it’s missing things like “query” and “assert” and other graph functions. was this what you had in mind, @melvincarvalho? could this be done with more support for RDF-like graph availability? or is there still more to it?
I didnt quite understand this either. What is the relationship to the second WG deliverable
Social API
A document that defines a specification for a client-side API that lets developers embed and format third party information such as social status updates inside Web applications.
There is possibly some confusion between AP C2S and Client Side APIs, such as oembed, which are still very much needed on the Social Web.
As you mentioned before, we had a lot more user stories than embedding.
You may want to look at how embedded experiences worked in Open Social. It’s very interesting!
Embedded experiences are interactive activities. In the fediverse this would be things like playing an attached audio file or video, or voting in a poll.
I think OEmbed is great for giving a rich embedded experience for links.
I also think Open Graph Protocol is a more common markup format for links, and it can also work very well.
One nice thing about ActivityPub is that it’s a “follow your nose” API.
Once you have a link to an Actor object, you can discover the list of all their activities (the outbox) and their social graph (following, followers), as well as things they’ve liked (liked stream).
With an object, you can find the thread it belongs to, its author, any replies and who has liked it.
@trwnh another thing you might be missing about AP C2S is that publishing activities has side effects. Activities act as a kind of social command language.
For example, publishing a Follow activity will add the object to your following collection, add you to their followers collection, and initiate a subscription relationship so you receive their activities in your inbox.
i can see that much, yes, and i think that this is a great accomplishment, but its scope seems very much focused around pub/sub and notify use-cases. the reader use-case is left somewhat open-ended aside from “GET inbox”. other use-cases like querying and graph-related operations are unspecified.
this is also all well and good, except that you need an entry point somewhere, and you also might need to work with knowledge that you don’t have. for example: how can you assert that you are following or followed by someone, without revealing the entirety of both your collection and their inverse collection? further still: how can you assert that you are a “friend” of someone? that you “know” someone? that you are “in a relationship”, “have a sister”, and so on? presumably we can lean on external vocabularies like FOAF, but it would be nice to have official recognition and guidance on things outside of pub/sub. and really, this can be solved by leaning more into JSON-LD and RDF, possibly at the cost of breaking some of the “plain JSON” guarantees of AS2, or possibly by making new, different guarantees. (i think it would be worth considering as a thought experiment whether “compacted form” was the right choice… perhaps expanded or flattened would have been better? as it stands, the use of compacted form makes it easier to work with AS2 vocab and nigh-impossible to work with any extensions if you don’t understand LD.)
this is something that i can see going both ways. Activities can have side-effects, if you are dealing with an ActivityPub conformant Server or Federated Server. they can also have side-effects set by some other “de facto spec” (Mastodon, Lemmy, Funkwhale, etc). they can also have no side effects, and serve purely as a notification that “someone did something”, to be displayed in a stream of such activities, perhaps a sort of “activity stream”. (heh!)
having said all this: i think there is probably further work to be done in setting standards and providing guidance for more use cases that fall under “social” or “social API”, but i think it’s important to identify what those use cases are, first. for my part, i can identify querying graphs and collections as something i’d be interested in collectively figuring out. for starters, a way to query if an item is in a Collection without iterating over the entire Collection. also, a standard way to request and view more than one object at once in a graph (perhaps flattened form, perhaps on-the-fly Collection generation, perhaps something else…).
Absolutely! It’s quite encouraging to see that this was already designated as a deliverable in the Working Group charter.
The current spec indeed allows for the extension of ActivityPub objects with Linked Data or even JSON. The ‘add a friend’ use case is a great example, which could easily be modeled with a JSON object. It’s important to recall that plain JSON can already be utilized in an ActivityStreams object.
What’s particularly beneficial is the ability to leverage the portability of these objects by incorporating them into social web apps. Various types of social interactions, such as status updates, games, videos, pictures, and music, can all be embedded in a web application. This is something we’ve already been implementing in Nostr and Solid, but it’s not sufficiently specified.
Should there be any interest from others in joining forces to develop this further, it would be a suitable project for the FEP process, the W3C note process, or an open-source process. Not only could it provide value for a variety of groups, but it could also lay the groundwork for new initiatives or a new W3C charter, considering it was a part of the previous charter and remains an unfinished task.
On the topic of relationships, I recommending reading over the Representing Relationships Between Entities section of AS2. FOAF and the Relationship vocabulary are explicitly called out.
You’re right in that the main way for exploring the social graph is to look at the followers/following collections. It’s interesting to consider representing a relationship between two Actors in a way that doesn’t expose information about other relationships. It would make an interesting C2S extension, and I’d be happy to work on it with you.
In terms of next steps: can you please add GitHub issues for each API addition you’d like to see? Right now, I’m counting:
Get a single relationship without traversing followers/following graph (great one)
Determine membership of an item in a Collection (also good; might cover the previous one)
Requesting more than one object (I’ve seen this called “boxcarring” in an API, but it’s not well attested in Google, so let’s just use this)
While I understand your point about using the Follow activity in the ActivityPub API to “add a friend”, it’s important to note a significant distinction. Following someone doesn’t necessarily imply friendship.
I kindly request that we maintain focus on the original topic to ensure productive dialogue.
I just re-read the OpenSocial Activity Streams API doc again, for the first time in probably a decade. What’s striking is how similar it is to ActivityPub’s C2S API. Thanks for the reminder, Melvin!
In both, there is a stream-oriented RESTful API, with CRUD methods. You can get a collection of activities and create a new activity with a POST.
Unlike ActivityPub, you can also PUT to update an activity, and DELETE to delete (or undo?) an activity.
It’s probably not a coincidence; REST is a really useful framework, and ActivityStreams are a really useful representation.
Ah. “Add a friend” in social networking parlance can mean both “establish a connection in the social graph” (which Follow does) and “declare a property of a relationship” (which Follow doesn’t).
@eprodrom, I appreciate your insights on the multi-faceted meaning of “add a friend” in social networking. However, to maintain the focus of this thread, I kindly suggest initiating a new topic for further exploration of your theory. Let’s keep this thread dedicated to its original topic.