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

ActivityPub
12

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

13

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 (public-swicg@w3.org from March 2023)

Let’s get something 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 :slight_smile:

That’s the straw proposal, please propose modifications.

Thanks,

Johannes.

14

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.

15

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 …

16

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?

17

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
18

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
19

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.

20

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
21

Evidence why I think ActivityStreams Core needs a rewrite:

If ActivityStreams Core simply stated: “All objects are Json-LD 1.1.” the entire confusion (including mine) could have been avoided.

Bonus content: Also note how messed up HTTP Signatures currently are! They depend on a correct interpretation of ActivityStreams Core.

1 Like
22

“All objects are JSON-LD” means that you lose the ability to treat them as “plain JSON”. The thing that allows them to be “plain JSON” consumed is the requirement to compact against the activitystreams context before presentation. The caveat is entirely in how extension contexts get included or not – you MAY compact against additional extension contexts, or you might not. AS2-Core warns that extensions might not be supported by all software because of this. There’s not really any getting around it, either – you can’t force people to understand the same context as you. It devolves into forcing JSON parsers to understand multiple different representations of term names:

  • the full IRI may or may not be understood
  • the term may be shared but without checking @context you have no idea if it’s the same. not recommended unless you explicitly target certain projects for compatibility
  • the ex:term compact term will almost certainly not be understood because the prefix may be anything

If I were to provide guidance purely from an ease-of-compatibility perspective, I would recommend ONLY compacting against the activitystreams context for s2s-related stuff. Any extensions SHOULD be serialized as full IRI, and then JSON-LD consumers can compact against whatever context they understand, if they wish to work with shorthand term names. But in practice, this isn’t how it works – implementations like Mastodon expect the same shortname as their context.

2 Likes
23

See this issue here on transient ids and types

It is unclear to me how well issues are resolved before they are closed

It seems to be the opinion of one person, with the aim to develop a primer

24

Melvin wrote:

It is unclear to me how well issues are resolved before they are closed
It seems to be the opinion of one person, with the aim to develop a primer

Yes, the recently closed issues were closed based on the opinion of one person, evanp, with a number of folk watching, and sometimes briefly commenting, as he reviewed the issues. The issue review is done via a scheduled Jitsi conference. Often, a closing results in an addition to the growing primer on the wiki. Thus, we’re building up a collection of commentary on previously stated issues in a somewhat organized collection that should make it easier for folk to resolve issues in the future. I think this is a good thing and that it is much better than simply leaving all issues open – as has been the practice in the past. Of course, if anyone disputes the closure, or the text added to the wiki, an issue can always be reopened or resubmitted with additional explanation.

What would be a better process?

bob wyman

1 Like
25

An extra pair of eyes would be good

In the WG we had a ‘commenter satisfied’ label to double check the issue was solved

A label could be added for this process, but it seems that you could just search based on time and user

Question is what happens if there’s a mistake? How do we know the resolution is correct. Was the subtype issue correct? Was the functional properties resolution correct? Was the resolution about @type correct?

26

Melvin asked:

Question is what happens if there’s a mistake? How do we know the resolution is correct. Was the subtype issue correct? Was the functional properties resolution correct? Was the resolution about @type correct?

If there is a mistake, then anyone who detects it can simply open a new issue that explains the issue. Those who agree, or disagree, can comment on the new issue. In time, that issue will also be resolved and a new cycle may begin. Why isn’t that better than leaving almost all issues open and unresolved, even after extensive comments, as has been the practice in the past?

bob wyman

2 Likes
27

I agree that opening new issues and engaging in discussions is an effective way to handle mistakes and move projects forward. In fact, this approach is employed quite successfully within, for example, Nostr

https://github.com/nostr-protocol/nips/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc

You can see the effectiveness of this approach by looking over half a dozen pull requests updated within the last 24 hours:

The success of this model largely depends on dedicated and knowledgeable leadership, operating in a timely manner. Unfortunately, not all projects, including the W3C repo, have had the same level of consistent attention and commitment. As a result, some issues have been left unaddressed for several years, which can discourage community members from investing their time and effort.

The issue about subclasses was closed, and the resolution didnt make a lot of sense. When I asked for clarification it, the resolution was deleted and completely changed. The question about functional properties was closed, and the answer in the wiki was a hand wavy commentary about “these properties”. Its not even clear what “these properties” are. I did ask for clarification on the issue, and there’s no reply.

Case in point can an actor have more than one inbox. Certainly when I developed the idea of semantic inbox, which lead to solid inbox, and then ldp inbox and then activitypub inbox the idea was that of an http version of email. While you might have one main email address, and one main semantic inbox, as a system grows large people often will have 2-3 inboxes for different contexts.

Id be happier if there was a two step process for closing issues. First adding a label. Then someone who knew linked data (e.g. sarven) could double check it, and close the issue. I’ve suggested that if an explanation is put in the wiki the exact version is linked. So let’s see if that improves things. It might work.

28

Melvin wrote:

“The question about functional properties was closed, and the answer in the wiki was a hand wavy commentary about “these properties”. Its not even clear what “these properties” are.”

Given the context of the issue, “these properties” are “Functional Properties.” That terminology probably comes from at least the Owl Vocabulary. The Owl definition states that “A functional property is a property that can have only one (unique) value y for each instance.” While ActivityStreams denotes the cardinality of some properties, ActivityPub does not. This may lead to some confusion and some implementers may produce instances of Functional Properties that have array values when they should not. So, those who consume data should be prepared to receive data that does, in fact, contain functional properties that do have array values. In other words, one should follow the standard rule that says “You should be strict in what you write, but liberal in what you read.”

I’m not sure I understand where the ambiguity is coming from.

bob wyman

29

He wrote: “Publishers should not include array values for these properties”

What are ‘these properties’?

https://www.w3.org/wiki/ActivityPub/Primer/Cardinality_of_properties

30

In terms of process wouldn’t it be better to stick to more common ways how Github project workflows are done?

  • There are many long-open issues. Original posters may have moved on, lost their interest to review.
  • There are deliverables to create: Errata, a primer, whatever-else-is-needed …

So that might be done with:

  • A project Kanban board: Todo, Triaged, In Progress, Review, Done.
  • Corresponding labels if needed, to add to the issues being processed.
  • Texts of deliverables are Markdown revision-tracked in the repo.
  • People assign to open issues, create PR’s to deliverables, update the board.
  • Issue and/or PR reaches Review stage. By rule N reviewers should approve.
  • Then the PR is merged and Issue is Done, gets closed.
  • Definition of Done includes → Update channel: W3C Wiki, Notify community: SWICG mailing list.
31

W3C does have this, e.g. with JSON-LD. That could work better, yes.

Github labels alone can be very useful.

1 Like