Re: Should the specs be forked and maintained elsewhere?

nightpool wrote:

> implementor consensus, which is in my mind the most important goal of a
> specification work group

Without "Implementer consensus," a standard has neither purpose nor
meaning. That is clear. However, I think it is important to remember that
there are at least two groups of implementers: 1. Those who have already
implemented, and 2. Those who are in the process of implementing, or would
do so, if the standards addressed their needs. It is also important to
remember that the first group is pretty conservative. They have a system
that works, they don't want it to break, and they undoubtedly have a long
list of things to work on that don't require modifications to the
standards. (GUI tasks are endless...) They also won't see much value in
"clean up" work to make the standards better structured, easier to
understand, etc. since they have already worked through any issues the hard
way. But, such clean-up can be very valuable to new entrants.

I'm in the second group. I am one of those who hasn't yet released
something and thus doesn't have a user-base to consume my time. In order to
build what I want, I need a few things that may not be top-priority for
those with existing systems. These include (non-exhaustive list):

   - *Signed Objects* (Leveraging the work of the W3C Verifiable
   Credentials Community Group) A lesser priority would be encrypted objects
   to allow private messaging.
   - *Rights Expression Language (REL)* (I would prefer a profile of W3C
   ODRL that at least allowed the embedding of Creative Commons license data
   in objects -- but I'd like to be able to do more than that.) A REL might
   find use in the implementation of a "Groups" facility as well as be the
   means for expressing grants of, or restrictions to, "Reply" capabilities.
   It would also address the search-engine-hating crowd's needs. (Note: To
   enable actual enforcement of rights, it would be necessary to modify the
   specs to explicit state that a REL may be used. This is necessary to be
   able to show that one who parses objects, according to the spec, has been
   given reasonable notice that license conditions may be embedded. i.e. to
   prevent statements like "I didn't know what those bits meant...")
   - *Annotation integration*.While this probably requires no spec
   modification, I think it would be useful to ensure that we have a shared
   understanding of what a service is supposed to do with a W3C Annotation
   Object or an object containing annotations.
   - *ActivityStreams integration with WebSub* for content fan-out and
   support for content-based filtering in WebSub subscriptions.
   - *IPFS integration* Object ids that are globally unique and can be used
   to de-reference objects based on their content, not their location on some
   server
   - *DID support* (Particularly as identifiers of post authors, and of
   intended message recipients in To, BCC, etc. fields)

Previously, the Community Group spent a lot of effort discussing and
> working on "outreach"-focused initiatives that didn't move the ball forward
> on technical integration.

I think Elon Musk has effectively solved the "outreach" problem. It is now
much less important to talk about ActivityPub and much more important to
ensure that systems that build on it have a technical foundation that will
allow them to serve orders of magnitude more users than have been served in
the past.

bob wyman