Re: Regular SWICG meetings and CG process

čt 30. 3. 2023 v 11:23 odesílatel Bumblefudge von CASA <
virtualofficehours@gmail.com> napsal:

> Hey all, great session yesterday, the energy feels a little like a tidal
> wave. Let's try to channelize it into well-distributed work that gets
> reused and built on for years to come. My thoughts, as a semi-professional
> catherder:
> On 3/30/2023 4:10 AM, Aaron Gray wrote:
>
> On Thu, 30 Mar 2023 at 02:46, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>> st 29. 3. 2023 v 21:12 odesílatel Johannes Ernst <
>> johannes.ernst@gmail.com> napsal:
>>
>>> On the call today, there was also the thought of having separate,
>>> smaller meetings focused on specific parts of the overall problem.
>>>
>>> The main categories of subjects that I wrote down were mentioned today:
>>>
>>> 1. Core ActivityPub spec issues / improvements (e.g. use of HTTP content
>>> negotiation)
>>>
>>
>> This is good!
>>
>
> 1.5. JSON-LD @context extension declarations and comprehension
>
>     https://json-ld.org/
>
> Yes, the core specs are LD-based and without a little tooling and harness
> work, it can be very hard to have interop deeper than the API layer.
> Hearing that Evan has pieces of and can revive a self-service validator for
> AS2 objects is great news, this feels like step 0 to me.  The LD wizards
> and the catherders need to work together on making this kind of stuff more
> accessible and self-service, so that newcomer implementers without an LD
> background don't smash their head against it and develop a deep, debatably
> justified grudge at that layer.
>
>
>>
>> 2. Significant potential extensions (e.g. cryptographic approaches to
>>> more privacy)
>>>
>>
>> Nomadic Identity is something that has been discussed on socialhub over
>> the years as a way to more easily migrate from one instance to another
>>
> ^ This is an FEP I would like to work on... once there is a clear baseline
> of conformance to core data model and AP-spec-defined C2S and S2S behavior
> established! The portability of accounts (and the enforceability of server
> obligations to support it) are my primary interest in the fediverse qua
> protocol and ecosystem. As Big Tech shows up and starts federating, many
> fedi-pundits have joked that it's the one corner you can be sure they'll
> all try to cut, erode, embrace, extinguish, etc. But you can't make
> portability enforceable (technically or legally) if more basic things
> aren't crystal-clear-- slippages compound as you move up the stack.
>

Good!  This FEP will be quite detail oriented.  Easier to get wrong than
right, so let's get eyeballs on it.


>
>>
>>> 3. Documentation and testsuite(s):
>>>   a) just for ActivityPub
>>>   b) for the entire stack needed to achieve real-world interop (e.g.
>>> “will it show up in Mastodon”)
>>>
>>> The "layers above" ActivityPub can't really be aligned without a
> Herculean labor until the ActivityPub layer is more definitively aligned. I
> think it's a stitch in time! For now it seems everything above AP data
> model is only roughly aligned, due to Herculean labors that many Herculeans
> on yesterdays call professed wanting to spare others.
>
> 4. Profiles (e.g. a minimal subset)
>>>
>>
>> Profiles require a lot of work as they tie everything together, and many
>> patterns are entrenched
>>
>> Less work if you're profiling multiple implementations that conform on
> the low-level stuff and use it as a precise and deterministic translation
> layer between them...
>

Translation layer would be nice, but this is also tricky.  Bear in mind the
nature of this technology is *declarative* so what actually is there
defines the system, rather than an interface or the API, that's something
inherited from linked data.  Bridge can be of value though, you need both
things.

Identity in the linked data part (not indieweb) seems a big chunk to
document and standardize and improve.

That would give a shot at adding content addressable globally unique
identifiers that offer a secondary anchor in identity, and reduce
dependence on domains

Just be aware that the divergence of identity has happened and we have to
work with it, and cant wish it away, getting changes upstream is still a
big task, so we have to be pragmatic


> Different projects are doing things in different ways, and theres bugs
>> that stay unfixed a long time
>>
>> Retrospec'ing ad hoc or pragmatic decisions isn't my favorite kind of
> design process.  On the call Aaron mentioned working on an Implementer's
> Guide that collates and processes implementer feedback-- this, paired with
> better C2S and S2S behavior conformance tools, seems to me the "next layer"
> to collaborate on if this group wants to move up one layer at a time from
> AP to APIs.
>

> Thanks,
> --
> ------------------------------
> @bumblefudge in a few places, including https://chainagnostic.org
>