Should we fork AS/AP specs to Codeberg, create vNext drafts?

I just commented on FEP issue Next steps for a proposal to become official W3C specs?

As can be seen in the notes of this pad as a kind of overview:

The W3C repo’s are full of issues and PR’s. Since creating that pad this has only grown. No one maintains these repo’s and yet there are errors in the spec and unclear texts, etc.

We might fork the specs to the same location where the FEP’s are currently maintained, the fediverse org. Deal with issues/PR’s there, and report back to people on Github trying to bring their changes.

Later on, should the W3C, via the SWICG or another Community Group, changes might be merged upstream again.


1 Like

not sure it should be done unless there’s any necessary changes that should be “upstreamed”. in which case, maybe a new charter with a clear purpose. it can’t be as vague as “the spec should be updated”.


I don’t think an update to the ActivityPub specification can be done in a reasonable time frame in a manner I would be satisfied with.

I think the approach of taking small steps, i.e. FEPs, is the correct approach at the moment. There are too many things happening to aim at creating a “central” document with any level of longevity.


It is to take care of these issues, and get something going in anticipation of maybe a new vNext initiative (at W3C or wherever). May not be be focused on vNext, just addressing amendments and corrections may already be valuable.

As I outlined in POLL: SocialHub Scope and Purpose? a 3-pronged parallel track makes sense to me, of:

  1. Open standards track → keep drafts until this gets underway, or turn forks into the new deal.
  2. FEP process
  3. Vocabulary extensions

I should mention in addition to the above, that a ton of people do not know that SocialHub community forum exists. Their interest for Fediverse leads them to the W3C repo’s and they find a dead wasteland. Having pointers that would lead them towards ongoing activity is also a help to ramp up FEP process activity and general discussions here.

If the W3C github repositories were to be integrated here, would it make a difference?

There’d be maintainers to the repo’s. Might find the maintainers of current GH repo’s as well, of course.

We actually have an access token to w3c/activitypub repo but not activitystreams. It would take a bit of work to setup in a useful manner, which is why it’s not yet ready. Maybe if someone from the @discourse team would help, then we could at least see if this option works for us.

@erlend_sh would you like to give a hand bootstrapping the GH plugin with me? We could take a couple of hours to sort things out and make it happen. Then at least we would be a step further.

Our “governance” is increasing going to be pushed and pulled in different directions, @how please hold onto #4opens in this #NGO #mainstreaming #fahernista #grassroots flows, thanks for your work.

I don’t work for Discourse any longer, so the Meta forum (and Angus & co. working on ActivityPub) is your best bet :slight_smile:

(Forum was down, hence this short reply by mail.)

1 Like

ActivityStreams and ActivityPub are W3C specifications, thus, the proper place for any formal discussion and maintenance is within the SWICG. It would not be appropriate to fork the specs and develop them outside that context. If one is concerned that SWICG is less than optimally active, then the best course of action would be to create activity on the list and suggest what needs to be done.


Thanks. I will also include a link to the SWICG mailing list thread on the same subject:

Follow up is calling for a meeting: Let's meet. Was: Re: Should the specs be forked and maintained elsewhere? from Johannes Ernst on 2023-03-23 ( from March 2023)

Let’s get something done.

I declare myself bold enough to call a meeting with the following proposed coordinates:

Wednesday, March 29, 2023, 10-11am pacific daylight savings time.

Where: Sean’s Jitsi
Room “ActivityPub”. (I can’t spell swicg and neither can my spell checker)

Anybody on this list
Anybody who cares about the future of ActivityPub and related efforts
Anybody attending FediForum (we will declare this to be one session so hopefully some attendees will show up here)

Collect views on the future of ActivityPub (and related) standardization
Emerge with some sense of common direction (or be more clear about where disagreements may lie)
A couple of next steps

I’m offering to play facilitator for this one meeting (no promises beyond that) although I would gladly not do that if somebody else volunteers. I’m just tired of waiting :slight_smile:

That’s the straw proposal, please propose modifications.



It’s a good idea. Even if we don’'t plan to make any changes, it would be nice to have a backup in case something bad happens.

I have done some thinking about it, spurred on by people saying no on some mailing list somewhere.

I actually already “forked” the ActivityPub Specification. It’s here. So if somebody wants to create something, at least I will find incredibly valuable, finish this idea:

  • Create a fork of the specification repo
  • Add labels to all the things that an implementation should satisfy
  • Create a tool that takes a codebase and looks for markers and adds these to the implementation version of the spec.
  • Make it look good!!

One might take inspiration from ActivityPub Implementation Report

Could you add that at the bottom of the wiki post in the list that’s emerging, @helge ?

PS. I forgot who started a website to document AP development. It was a recent announcement, dedicated domain. Would like to gauge if they wanna join on Codeberg with that. Anyone?

If someone starts working on upgraded specification documents

Activity Streams Core definitely needs to be revisited first or discarded. I would expect this to be the place, where the requirements on an ActivityStreams object are clearly stated. So it should be something like:

  • ActivityStreams Objects must be Json-ld
  • ActivityStreams Objects must have a type
  • ActivityStreams Objects with id are called transitive (is this a good name? I think it’s the one the documents use).
  • transitive ActivityStreams Objects of type Activity must have an actor property, a published date, and an object property, and for certain types a target

and so on. Having clearly defined minimal requirements will enable better interoperability.

1 Like

why? it works

as2 documents are consistent with json-ld compacted form given the activitystreams context document, but can otherwise be parsed as plain JSON

why? it’s just an optional hint. the only types that matter are the Activity subtypes, which have defined side-effects only within activitypub.

if you mean “transient” (passing), then this is the word used for objects without an id. if you mean “transitive”, then an “intransitive” activity is one without an object. i don’t know what it’s like in other languages (it probably varies), but in English, we have sentences in the form subject-verb-object-target, and only subject and verb are required. object is required if the verb is performed upon something. target is required if the verb is performed to/from something.

actor is what defines an Activity, so this is a tautological statement to some extent.

i see no reason to require published, and the use of object and target is already specified in activitypub per the English rules above.

Clients submitting the following activities to an outbox MUST provide the object property in the activity: Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo. Additionally, clients submitting the following activities to an outbox MUST also provide the target property: Add, Remove.

Servers performing delivery to the inbox or sharedInbox properties of actors on other servers MUST provide the object property in the activity: Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo. Additionally, servers performing server to server delivery of the following activities MUST also provide the target property: Add, Remove.

1 Like

The next sentence I wrote answers this. I’ll repeat it: I would expect the ActivityStreams specification to be the place, where the requirements on an ActivityStreams object are clearly stated.

If your argument is: They are stated in the ActivityPub Specification, then it’s a vote to discard the ActivityStreams Specification.

to clarify:

  • as2-core is about the structure of the document
  • as2-vocab is about what goes into that document
  • ap is about the side-effects of documents containing certain vocab

it’s all predicated on having as2-core as the foundation. everything else extends from there.

1 Like