Hey, Melvin. You asked for clarification and I provided a clearer answer. There is no way a clarification can happen that does not involve change.
Right now, I’m working from the oldest issues forward. I do a weekly livestreamed triage. I am switching off between AP and AS2 week by week.
is there any Activity which doesn’t have an
actor? why can’t we unambiguously say/clarify that any as2 document POSTed to outbox MUST NOT be wrapped in a Create if it contains
- Leaving the
actorout of activities in the outbox is a pretty natural optimization, since all the activities will have the same actor.
- We don’t need to make normative changes to keep this easy for client and server! If you’re a client, and you want to be well understood, don’t use the Create shortcut for object types that aren’t in AS2 Vocabulary, and use the multiple types format for Activity objects that aren’t in Vocab.
Its a case of trying to understand what was written. The process of learning and understanding does not necessarily mean that the material presented needs to change.
What about taking the FEP process and making it into a W3C note?
I like that idea. If this is an option (depending on feedback) could you all then update the wiki on increasing cohesion between independent initiatives?
Along with making the FEPs an official W3C Note, I have suggested a path towards standards compliance here:
the client doesn’t have anything to do with this – it’s the server that decides to wrap in a Create. and the server can’t (and shouldn’t) be aware of every single extension activity type a priori.
what about inbox forwarding? some activities will be performed by a different actor.
I think that would be very cool. SWICG can publish notes.
Of course. Wikis can be confusing if you’re used to conversation mode. Changing the full document is the main way to make improvements. Fortunately there’s a document history function that lets you find older versions.
Yes, I understand that it’s the server that does it!
If you are writing an AP client, and you want to have reliable behaviour from different servers, don’t use the Create shortcut for extended types. You’re depending on the server to figure it out, and that’s not going to be reliable.
I’m not sure what to tell you about outboxes that don’t have the same actor for every activity. I don’t think it’s possible as specified. I’d guess if it were the case, don’t leave out the actor property!
So, joining a CG call or posting to the CG mailing list does not require membership or signing anything.
However, to make any significant contribution to the spec, requires signing the IP agreement (which protects the CG against patent trolls).
This is great! Do you by any chance have some instructions on how to do that? I could try and figure it out, if not.
To be able to contribute, go to the CG homepage https://www.w3.org/community/SocialCG/ and click Join. This will prompt you to fill out the Contributor Agreement (W3C Community Contributor License Agreement (CLA) | Community and Business Groups)
To just sign up for the mailing list (which you’re already on, but I mention in case others are curious) - does not require joining the group or signing the CLA, go to email@example.com Mail Archives and click on the Subscribe link.
Perfect, I think a lot of people didnt know that, so were not participating.
I did a second pass, and changed “these properties” to be more specific about which properties to be careful with.
but how is the Client supposed to decide what the Server does? the wrap-in-Create behavior is automatic, and so the Server needs a way to identify an Activity without having to be aware of every single extension. if it doesn’t have this, then the behavior is under-specified and the spec is incomplete and in need of revision.
in my opinion, such a revision doesn’t have to be drastic or backwards-incompatible, but there are various “logical implications” due to the normative language used in the spec. some requirements imply other unstated requirements. i am currently trying to (very informally) document such rough edges on my personal wiki whenever i encounter them, but my hope is that the problems identified can be fixed or clarified “upstream” by anyone who has the authority to make changes or revisions to the spec docs or the normative context. we might have meetings of the SWICG / SocialCG to discuss these as formal resolutions once they are compiled fully.
mainly, i have the following points recorded regarding the core data model:
- an Activity has an
actor. if it didn’t, it wouldn’t fulfill the actor-activity-object semantics. (i remain unconvinced that you can “assume” the actor from outbox; indeed, you cannot tell you are looking at an outbox unless you already know some actor!)
- an actor has
outbox. if it didn’t, it couldn’t pass messages, and would not meaningfully be able to do anything.
- a Link has an
hrefinstead of an
id. if this wasn’t the case, it would be an Object.
- a Collection has
- an OrderedCollection MUST be reverse chronological in ActivityPub, but it can be any order in ActivityStreams. (i have seen comments that indicate this wasn’t the intention, but that’s not what the spec says!)
regarding semantics of type and property definitions:
Articleshould have been like an HTML
<article>. (the stuff about length and paragraphs is directly contradicted in multiple examples throughout the spec docs.)
Mentionshould have been like a webmention, not an @ mention. (there is nothing special about an @ mention, and mentions do not have to be @ mentions, they do not have to start with @, etc.)
Organizationshould never have been defined in ActivityStreams. they should have been imported from vcard or foaf or some other ontology/vocabulary. (some implementers have very incorrect ideas about these, such as assuming a
Groupis a facebook-like “group”. this is an equivocation between two different definitions of “group”, and it is something that
@contextwas intended to solve.)
Serviceis utterly useless. “Represents a service of any kind”? there are like a dozen different definitions of the word. helping someone, performing maintenance, religious worship, copulation, etc… and frankly, none of the definitions are suitable. in most cases,
Applicationis just inarguably better.
contextis “intentionally vague” to the point of being useless. (FEP-7888 attempts to resolve this by examining various dictionary definitions of “context” and relating them to the concept of a resource.)
regarding the normative context:
- formally define and adopt
Hashtag? many people are just defining these as unofficial extensions within the activitystreams namespace, and have been doing so for years.
there’s more that i’m trying to collect from thoughts and fedi posts and other sources, but the general impression that i have of the spec documents is that they are poorly written despite being theoretically well-founded. (i didn’t even cover things like “inbox forwarding” being given a whole subsection in activitypub without a single hint on what it even is or looks like or how one might perform it)
i suspect that this sorry state of the spec docs is why people keep having the idea to “fork” or “rewrite” or “create vNext” or whatever. for what it’s worth, i don’t think this is necessary, but what is necessary is a massive clarification of what we already have.
because as it stands, no one is doing activitypub. there are basically zero compliant implementations of any of the Client, Server, or Federated Server profiles defined in activitypub. it is more appropriate to say we are just doing AS2 + LDN (Linked Data Notifications). the side effects of an activity being delivered to an inbox are more accurately and appropriately defined by individual implementations than they are by activitypub. we have the mastodon protocol, funkwhale protocol, lemmy protocol, etc. – and only incidental compatibility between them, due to their partially shared use of AS2. you could implement a fully compliant activitypub client/server, and it would be wholly incompatible with almost everything in the current fediverse. the only ap-s2s side effect that is nominally followed is Follow… and even that diverges from actual practice, not least of which is due to addressing followers collections in activities send to
sharedInbox (where the receiving server is now expected to know the contents of a collection it doesn’t have access to!)
it’s a bleak picture i’ve painted, sure, but there is still a path forward imo, and it involves actually cleaning up the messy “unfinished business” in the specs. if this isn’t done by SWICG then it will be done by the community, and you’ll end up with a de facto spec/network fork anyway.
(aside: i myself am not very interested in continuing to build only within the limits of what mastodon deems realistic, and i think there is more value in “publishing to the social web” than there is to “posting on social media” – so something based more around explicitly managing collections, using Add instead of Create, allowing cross-domain authorization and browsing at the origin, and overall making affordances for generic activities rather than “RPC but more verbose and inefficient”… that’s what i’m interested in. a more tightly-controlled, closed federation that empowers users to choose who actually has their data and information, which servers they send their activities to. something that allows for more than just “posts”, something which we can use to publish and discuss and message and read, with distinction between those four things.)
Solid’s utilization of either FOAF or vCard for Person identification could have significantly enhanced interoperability, aligning with our long-standing identity practices. We earnestly requested the AS/AP to follow this approach, a process that could have naturally occurred given FOAF’s extensive implementation, traceable back almost 15 years to Evan’s identi.ca effort. To facilitate a unified social web, Solid engaged Amy Guy to represent our interests, though unfortunately, interoperability wasn’t given the highest priority. Regrettably, a new identity system surfaced, leading to a divergence in linked data efforts. Despite the substantial overhead incurred, the anticipated benefits remain unrealized.
I think I said it pretty explicitly: a client should send the most specific Activity objects it can to avoid unpredictable behaviour by the server. I gave some suggestions on how to do that.
It’s definitely possible to use FOAF, schema.org, and other vocabularies in AS2.
The Social Web Working Group voted on the AS2 vocabulary, based on inputs from AS1.
I can’t remember exactly why FOAF, schema.org, and vCard weren’t incorporated directly, but I think it was primarily because we had a complete socially-oriented vocabulary coming from AS1, and we decided to use that as a base.
I believe there were also some problems with intellectual property on schema.org at the time. Maybe some sort of asymmetrical relationship? Like, it was OK to publish schema.org, but you needed a license to publish a consumer? Again, it’s been a few years.
You can read the minutes from those meetings of the Social Web Working Group. I think they’re pretty well documented.
Thanks a lot for the hard work you put in collecting these issues. Extremely interesting and helpful! I definitely think of
Group as a Facebook group, and
Service as a web service, like mastodon.social or fedifinder.glitch.me. It’s interesting to hear that they seem open to interpretation. Clearly something worth documenting!
I also think the reverse-chron requirement only applies to properties defined in the AP spec. If you add extension properties, or if you have Collections referenced in an Activity, they don’t have to be reverse chron.