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.
this is advice that only works when you stay within the AS2 vocab and you are working with semantic concepts that mostly map onto the defined AS2 vocab. it completely fails when you are dealing with extensions and extensibility.
say you have an
Eat activity, or
Message, or any other type defined by an extension. how does any generic server know it’s an activity? does every single server have to add support for every single extension? that seems ridiculous! instead, we can clearly define that “an activity has an actor”, and in doing so, we no longer have to care at all what the exact type is. all it would take is to clarify that the “wrap in Create” behavior should only be applied to documents without an
actor, instead of only being applied to non-activities. you end up with the same result, while removing ambiguity and being explicit. and explicit is better than implicit. this is stuff that should be specified beforehand so that servers don’t have to make decisions for themselves on what constitutes an “activity”. quite understandably, some server implementer might hardcode types and this would be a bad decision that breaks extensibility.
i’m suggesting something more like how
ldp:inbox was plucked out of the Linked Data Notifications spec and placed into the ActivityStreams context. so the same could have been / be done for FOAF and/or VCard. it seems to be a matter of preference on which one to rely on, but my weak preference would be FOAF because the semantics are closer to what ended up in the AS2 vocab – a
foaf:Person is almost exactly a match for an
as:Person, but slightly less so for a
vcard:Individual; and so on. although, i’m sure some might argue for VCard instead, as that one has an RFC associated with it. or you could use both. i’d propose the following context term definitions:
foaf:membermight be useful to adopt as well
this puts us in a very interesting conundrum, though… such changes would technically only “break” the JSON-LD interpretation of AS2, and not the “plain JSON” interpretation. compacting against the normative context would result in the same shorthand terms; it’s only LD parsers who would have to be prepared to accept and understand different IRIs. then again, IRI equivalence is an open problem in RDF and JSON-LD, with solutions to this problem usually involving the use of
owl:equivalentProperty somehow. i admit to not fully knowing or understanding how we might definitively declare that
foaf:Person is equivalent to
vcard:Individual, or even if this is indeed the case. (i think it’s possible in RDF/Turtle but not in JSON-LD? unsure)
yeah, from my understanding, this is something that some people seem to assume, but it is not something that holds unambiguously. you might call
mastodon.social an Application, for example. as for groups, i think that definition of a
Group might be better tied to whether it has
members or not; otherwise, you might have a separate definition that a
Group is an actor/agent representing an informal collective of people, kind of like an
Organization but without the structure. whatever the case, more documentation, clarification, and specification is needed.
then this language in AP section 5 needs to be changed:
OrderedCollectionMUST be presented consistently in reverse chronological order.
this would represent a normative change, though, as the requirement is being relaxed from “an OrderedCollection” to “any property defined by this document as an OrderedCollection”.
tangentially, i think that collections themselves, whether ordered or unordered, are quite underspecced. it would have been nice to have some way of expressing how a collection’s items are ordered, such as the index being used, whether the order is ascending or descending, and much more. curiously, there is
startIndex defined for
OrderedCollectionPage, but no concept of an “index” otherwise.