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.
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.
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.
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.
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.
I declare myself bold enough to call a meeting with the following proposed coordinates:
When:
Wednesday, March 29, 2023, 10-11am pacific daylight savings time.
Where: Sean’s Jitsi https://meet.privacysafe.io/
Room “ActivityPub”. (I can’t spell swicg and neither can my spell checker)
Who:
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)
Objective:
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
That’s the straw proposal, please propose modifications.
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.
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.
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 outboxMUST 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.
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.
