Reconciling theory and in practice -- do the specs need updating?

Obviously it’s great to have the Activity* specs. Without them, chances are we wouldn’t see the current (re-?) surgence of the Fediverse.

However, as somebody who is attempting to implement code that actually interoperates, out of the box, with as many Fediverse apps as possible, I consider the specs by themselves not particularly helpful. That’s because the actual protocol stack needed to interoperate with any particular app tends to be both a superset (e.g. also includes webfinger, HTTP signatures, app-specific stuff etc) and a subset of the spec. So to get interop working, in practice, one needs to think of how to support each app separately, even if there is a common code base.

So in practice we have an N**2 problem, something a common standard is supposed to avoid :-)

Note: this is not criticism of the work done at all, or the specs, or the community. This is what always happens and for good reason, because people learn and create new stuff and a standard, in the best case, can only be a snapshot in time.

It seems to me we should have a conversation about updating the specs, including the ones created run the W3C, but also other standards (like WebFinger) and conventions that in practice are required to be agreed on, otherwise interop out of the box is not possible.

(I am aware of FEPs on Socialhub, but I’m not talking about this. I’m talking about the core specs.)

I guess we have several choices:

1. Attempt to reactivate W3C Social, and go through a formal process to update the spec. Formally reach out to IETF and simultaneously update Webfinger. Get extra standards work started that currently has no home. Pro: all nice and proper. Con: expensive in work time and calendar time and there may not be resources for this.

2. Declare Mastodon the market leader and whatever it implements as the standard. (I’m only partially kidding; this is what will happen by default if we do nothing.)

3. Something in between those two extremes. For example, we could create an updated “implementor’s guide” that says “do this, don’t do that, to be current in 2023” AND make sure that implementors understand that’s the baseline to work from. In the meantime, for example.

Many other choices … other ideas on need and how to address the need?

(I’m aware that I have little standing here, fairly new to this list, and so I’m not sure I’m the right person to raise this issue. But it is a real issue that affects people like me attempting to write interoperable code, and given that nobody has raised it lately I figure I might as well …)

Best,



Johannes.

Blog: https://reb00ted.org/
FediForum: https://fediforum.org/
Dazzle: https://dazzle.town/