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

The number one issue I see with new AP developers is that they run straight
into the HTTP Signatures requirement and try to read the spec and just give
up. >75% of the AP implementation troubleshooting we do with new developers
on social hub is http signatures related. (the rest is mime types)

On Fri, Sep 15, 2023, 12:53 PM nightpool <eg1290@gmail.com> wrote:

> additional http hits are very cheap and simple and since they're required
> anyway I think it's important to support them for cases where HTTP
> signatures aren't worth the complexity.
>
> On Fri, Sep 15, 2023, 12:50 PM Evan Prodromou <evan@prodromou.name> wrote:
>
>> We’d also need some failover methods. "If (new style) doesn’t work, fall
>> back to draft-savage, …”
>>
>> I don’t love the dereference style. It requires an additional HTTP hit
>> per delivery!
>>
>> Evan
>>
>> On Sep 15, 2023, at 12:05 PM, nightpool <eg1290@gmail.com> wrote:
>>
>> Historically a big blocker with HTTP signatures improvement is that it's
>> a working draft of the IETF that's undergone a couple of changes in editors
>> and been abandoned a few times. My understanding is that the httpbis
>> working group is currently in charge of standardization but there hasn't
>> been much engagement from the social web community since ietf working modes
>> are kind of baroque and hard for developers to engage with.
>>
>> A comprehensive authn spec for AP should probably support a simpler
>> "dereference" mode for activities as well, where the activity itself is
>> discarded and used only as a notification for which new resources to fetch
>> from the origin server. I believe Pleroma currently implements this and
>> it's desirable to decrease complexity for first time developers and
>> prototype systems (while http sigs are probably still required for
>> performance improvements on production systems)
>>
>> On Fri, Sep 15, 2023, 11:58 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/
>>>
>>
>>