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.
“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:
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 compatibilityex:term compact term will almost certainly not be understood because the prefix may be anythingIf 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.
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
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
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?
So that might be done with:
W3C does have this, e.g. with JSON-LD. That could work better, yes.
Github labels alone can be very useful.
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.
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.
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.
@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.
Hey, Melvin! Glad to see you here! If you’d like to talk to me, feel free to tag me at @eprodrom .
It’s part of our job as editors and authors to service the questions on the GitHub repo.
Here are the resolutions I have in the triage section:
So far, most of the issues closed have been questions, so I’ve mostly been documenting the answers with examples on the wiki.
Your suggestions have helped with the documentation effort. Thanks for it!
Hey Melvin! Wow, a lot of questions here.
Here’s the link to the document on identifying Activity objects:
https://www.w3.org/wiki/Activity_Streams/Primer/Identifying_Activity_Objects
I think it covers the best options. I think context is going to cover the most interesting cases, although AP’s unfortunate implicit Create rule messes it up a bit.
Hey @eprodrom, thanks for the extra details.
The issues and processes in the AS2.x and AP1.x branches appear to be improving. We must consider AS/AP’s interoperability with itself and other systems.
Im am starting to come to a conclusoin that a standards best approach may work best, as deviating from them can cause overheads without clear advantages. Developing a fully standards-compliant v.next might address scaling issues for the network.
Ultimately, the network must decide its preferred approach. It could be feasible to create a signaling mechanism for upgrading the network, as demonstrated by many OSS projects. However, this would require support from larger players. I would say that it needs to be inclusive, and that not every OSS developer will get employer permission to sign W3C legal agreements.
There are many successful FLOSS standardization efforts. As you rightly state a W3C logo took a lot of effort to get. But it’s there now. And the barrier to create a subsequent note is relatively low.
I think I mention “the inbox” and “the outbox” in the previous paragraph.
https://www.w3.org/wiki/ActivityPub/Primer/Cardinality_of_properties
Inbox and outbox, and most other properties of the Actor in AP, are mentioned in the singular in the text. There’s no specification for resolving multiple inbox or outbox endpoints. Most implementations I’ve seen have a single value for inbox and outbox.
So I documented a Postel best practice for handling them. Consumers will expect a single value, so Publishers should take care in using multiple values. Defining an extension for multiple inboxes would probably be a really good idea!
Publishers may add multiple inboxes, and that’s technically valid AP and AS2, so I added a suggestion for consumers to be ready for it.
If you think there are better practices, please let me know!
Thank you for the clarification. I did inquire in the issue and received a response.
I expect he meant all of the Actor properties mentioned in the original issue description
It seems we have two different answers across three platforms (forum, issue, wiki).
If you think there are better practices, please let me know!
I wasn’t implying that; I was just attempting to understand the provided information.