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

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

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

“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

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

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

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?

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

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.

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

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

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.

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

Github labels alone can be very useful.

1 Like

Hi all, couple of thoughts to add to the discussion here.

We’ve restarted the W3C SWICG (SocialWeb Incubator Community Group), in the sense of, we’ve re-activated the mailing list (it was disabled for years), and are planning to restart regular CG calls (monthly to start with, see the Doodle poll for preferred call times, the first one will probably be next week (week of Mon May 15)). Given that the group hasn’t met for a while, we’ll likely be holding CG chair re-elections shortly.

Activity has also picked up on the core spec repositories. Evan Prodromou (@eprodrom), editor of the ActivityStreams 2 Core spec and author on the ActivityPub spec, has recently been going through the open issues, and updating the spec Wiki (with errata, implementation guidance, etc).

While I do think reviving the W3C SocialWeb CG may be useful (for those sections of the Fediverse that are W3C-friendly, or as a step in the process of potentially chartering another SocialWeb Working Group and updating the specs sometime in the future), I also want to acknowledge that the current nexus of discussion and specification work resides here, on SocialHub, and on the FEP repo. (And also want to give a shout-out to the Fediverse Devs Matrix channel.)

Far from wanting to split the community, I’m personally strongly committed to making sure the SocialWeb CG is aware of, and is working closely with, SocialHub, FEP, Fedidevs, and any other existing communities.

So why do I bring up the CG on this thread? One reason is, to invite all the folks here interested in advancing the state of the AP/AS specs, to join the discussions starting up the community group.

Two – personally, I think that this very moment is not the best time to try and charter an AP 2.0 spec or a new Working Group, and it probably makes more sense to continue to work in shorter specs on the FEP repo.
But that’s just a current personal opinion, the community might have other strong preferences.

5 Likes

Hey friends.

So, I’d say it’s a very bad idea to fork AS2 and AP right now.

When there are multiple competing forks of a protocol, it hurts adoption of all of them. Developers don’t know which to implement, so they implement none of them.

Additionally, AS2 and AP are extremely flexible. An empty object {} is valid AS2, and the spec allows any property to be added as an extension.

The W3C logo at the top of the specs is worth a lot. We worked really hard to get them. It doesn’t make sense to throw them away so easily.

Keeping AS2 and AP as a bedrock base, and building on top of them with extensions, is the best way to further develop the fediverse.

4 Likes

One thing should be clear: it took us years to get the W3C to consider social web standards. The WG was chartered only because certain members of the organisation were convinced to abstain rather than vote against the charter.

Rechartering will be hard to do. I would not plan on it without some really strong arguments and a lot more momentum.

4 Likes

@codenamedmitri, could you please clarify the options for following or replying to a thread without being a member?

I believe this was possible, but a staff contact might need to confirm. Considering that AP/AS has significantly evolved over the past seven years and become deeply rooted in the FLOSS community, it’s essential to be inclusive, as not every FLOSS member can join a CG or obtain employer permission.