Re: Regular SWICG meetings and CG process

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