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

I would like to see Activity Stream extended to be able to deal with a
Post-Comment-Like format and also a Post-NestedComments-Like format as
well. With interop defined for working with the normal AS2 Note-Reply
format.

On Fri, 15 Sep 2023 at 19:01, Ryan Barrett <public@ryanb.org> wrote:

> On Fri, Sep 15, 2023 at 9:46 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.
>>
>
> Definitely understood! I'm not opposed to it. I just see all the clear
> need for standards work on the parts of the fediverse that *are* widely
> adopted and used - AS2, S2S, HTTP Sigs, WebFinger, etc. - so I worry about
> the opportunity cost of spending any time and effort on a languishing C2S
> instead.
>
> Another way to phrase it would be, C2S has plenty of features and
> functionality, but S2S took off and C2S didn't, so it doesn't seem like new
> enhancements or functionality would necessarily spur adoption. If we do
> spend more time on C2S, are there other things that might be more
> worthwhile?
>
>
>
>> 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/
>>
>>
>>
>
> --
> https://snarfed.org/
>