Social API for Client Side Apps

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]

1. Social Data Syntax
2. Social API
3. 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.

Looking forward to hearing your thoughts.

cc: timbl (solid)

Links:
[1] https://www.w3.org/2013/socialweb/social-wg-charter.html
[2] https://www.w3.org/Submission/2014/SUBM-osapi-20140314/
[3] https://oembed.com/
[4] https://github.com/solidos/solidos

Received on Thursday, 18 May 2023 13:35:44 UTC