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

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