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

It would be nice to unify as many of the edge cases of replies / comments /
conversations that currently exist in various implementations as possible.
AS type, privacy/visibility, ownership/permissions, self-replies vs others,
blocking/revocation, collections/ordering, backfilling/syncing, etc.

Maybe solutions to these are CG/FEP level, too complex or breaking for the
WG.

On Thu, Sep 21, 2023 at 12:29 PM Bob Wyman <bob@wyman.us> wrote:

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