Re: AS2/AP tasks for a chartered social web working group

Comments from myself, a newbie.

+1 for Evan’s C2S enhancement ideas (if they are general enough to be
useful throughout the fediverse). Would these require new AS vocabularies
or new standardizable actor endpoint names? Would there be standardizable
parameters for these endpoints, to filter replies, etc.?

Also I would love to see any applicable OAuth2 guidelines. Not being
well-read, I wonder whether something like IndieAuth would be appropriate?

Although as described above most likely they should go through CG/FEP
processes before being brought to the proposed WG.

WRT HTTP sigs, is there a compatible path going forward? Seems like other
FEPs and protocols are leaning toward CBOR-based signatures and
verifications. Can new methods have fallbacks to existing implementations?

—Peter

On Fri, Sep 15, 2023 at 9:47 AM Evan Prodromou <evan@prodromou.name> wrote:

> I love the ActivityPub API. I think it’s a real gem and it lets us support
> lots more social interactions than just microblogging.
>
> I’ve already created a couple of FEPs for enhancing it — having access to
> pending follows/followers, blocklists, etc. I have a few more in draft
> format, like doing some fine-grained feeds (home timeline, notifications,
> etc.), lists, and an OAuth 2.0 profile as mentioned. I think there’s a lot
> of innovation still to be done here.
>
> I would be firmly opposed to deprecating it.
>
> Evan
>
> On Sep 15, 2023, at 11:57 AM, Ryan Barrett <public@ryanb.org> wrote:
>
> Hell yes! Thanks for the explainer, this all makes sense and sounds good
> to me. I'll especially +1 the HTTP Sigs work.
>
> Maybe also consider something about C2S? Specifically, S2S adoption has
> obviously grown massively in the fediverse, but C2S hasn't. What's the
> conclusion and path forward? Double down on it somehow? Keep it but don't
> spend much effort on it? Find a path to sunsetting it?
>
> On Fri, Sep 15, 2023 at 7:53 AM Evan Prodromou <evan@prodromou.name>
> wrote:
>
>> One of the topics that came up at last week’s TPAC was the possibility of
>> having a new iteration of the Social Web Working Group.
>>
>> For those unfamiliar with the structure of the W3C: working groups are
>> necessary for making normative versions of standards documents. Many areas
>> of interest at W3C have standing working groups that just stay around
>> indefinitely working on particular topics. The Social Web Working Group, by
>> comparison, had 3 deliverables (social data standard, social API, social
>> federation protocol) and a fixed time frame.
>>
>> In order to create this working group, the W3C would have to make a list
>> of tasks for the group, and would need to put that list in front of the W3C
>> members. Then, the members vote on it, and if they agree, a new working
>> group would be born.
>>
>> W3C staff asked if we, the SocialCG, wanted to suggest a list of tasks
>> for that charter. They don’t have to use that list verbatim, but my guess
>> is that they wouldn’t edit it much.
>>
>> I’d like to suggest that we keep the scope of the WG limited to
>> maintenance of the existing recommendations. Other work that we’ve been
>> discussing, like the extension policy, testing, data portability, and other
>> topics should stay as part of the CG.
>>
>> I also think we could and should commit to a) strict backwards
>> compatibility and b) hewing closely to current practices. I would call any
>> new specs “1.1” or “2.1” to show that these are iterative, compatible
>> changes.
>>
>> Here would be the two main things I think we could do with a WG:
>>
>>
>>    - Incorporate editorial fixes from the ERRATA, like fixing incorrect
>>    examples. Many people read the recs and never see the errata, so getting
>>    those documents updated would really help them a lot. We might b
>>
>>
>>    - Eliminate some of our "AirBud
>>    <https://www.youtube.com/watch?v=Jvf0WWxrYRM>" issues, where the
>>    documents refer to standard practices in social networking, but we did not
>>    specify clearly in the specification itself. For example: the collection of
>>    followers should be unique. An actor should have only one followers
>>    collection. These would need to be carefully done to avoid making changes
>>    that aren't backwards compatible, but I think for a lot of them there's
>>    clear consensus in the implementations, and we'd just need to document them.
>>
>>
>> Here are a couple of things I think we could do that would be a stretch:
>>
>>
>>    - An OAuth 2.0 profile for ActivityPub API. We left authentication
>>    out of the original spec, and I think it’s made it harder for implementers.
>>    That said, I think this should probably be a FEP first before being part of
>>    the spec.
>>
>>
>>    - Document the use of HTTP Signatures. This might be the only place
>>    I’d suggest an upgrade; the AP world mostly uses an old draft of HTTP
>>    Signatures that is not compatible with the current versions. It would be
>>    nice to figure out an upgrade path for this and make it easier for
>>    developers to move forward.
>>
>>
>> We’d need to make sure that it was clear that any auth stuff is only a
>> mapping, and that you could use other auth types if you want and can get
>> interoperability.
>>
>> I think we could help the ActivityPub implementer community with new
>> versions of the specs.
>>
>> I hope this helps with the discussion.
>>
>> Evan
>>
>
>
> --
> https://snarfed.org/
>
>
> --
Peter Zingg