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

Aaron,
What is a "Post-Comment-Like format" and a "Post-NestedComments-Like
format"??? Please elaborate or point to a spec.

bob wyman

On Thu, Sep 21, 2023 at 3:11 PM Aaron Gray <aaronngray@gmail.com> wrote:

> 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/
>>
>