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

ActivityPub
61

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 inbox and outbox. if it didn’t, it couldn’t pass messages, and would not meaningfully be able to do anything.
  • a Link has an href instead of an id. if this wasn’t the case, it would be an Object.
  • a Collection has items or orderedItems.
    • 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:

  • Article should have been like an HTML <article>. (the stuff about length and paragraphs is directly contradicted in multiple examples throughout the spec docs.)
  • Mention should 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.)
  • Person, Group, and Organization should 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 Group is a facebook-like “group”. this is an equivocation between two different definitions of “group”, and it is something that @context was intended to solve.)
  • Service is 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, Application is just inarguably better.
  • context is “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 movedTo, sensitive, manuallyApprovesFollowers, 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.)

3 Likes
62

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.

63

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.

64

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 Attack, 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:

  • Person → foaf:Person instead of as:Person
  • Group → foaf:Group instead of as:Group
    • member → foaf:member might be useful to adopt as well
  • Organization → foaf:Organization instead of as:Organization

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:equivalentClass and 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:

An OrderedCollection MUST 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.

2 Likes
65

I’d definitely vote for Person - Schema.org Type over foaf:Person. How long are we going to keep using that ancient vocab that still has AOL Instant Messenger address built into it?

66

Great post, @trwnh .

You’ve rightly pointed out that ldp:inbox was derived from Linked Data Notifications. However, it’s even more intriguing that it was originally inspired by solid : inbox, an idea I had conceptualized earlier as “Semantic Inbox”. The concept involved web inboxes for exchanging structured, semantically-rich data, much like email.

During the development of SWWG, Tantek was quite against linked data. Despite being led by the founder of W3C, solid faced potential exclusion from SWWG due to indieweb’s dominance in voting. This led us to create a spec over a weekend to satisfy their requirements. The anti-linked data sentiment was strong, which I now understand was due to many years of both technical and people issues related to linked data.

Getting linked data approved by the WG was challenging. Arnaud’s association with IBM helped push AS2 through. Linked Data Notifications was an attempt to subtly introduce linked data to the WG, using a webmention-style predicate ldp:inbox to link a person and an inbox.

I initially disagreed with this approach due to security concerns. ldp:inbox could be set in the header, unlike the solid : inbox, leading to potential loss of user data control. I still favor solid : inbox for its superior security, especially for high-value transactions. However, the landscape allows for the mixing and matching of terms, making it a cooperative yet competitive space.

67

13 posts were split to a new topic: Provide FEP process pathway to further W3C SocialCG formalization

80

I think it’s inaccurate to say that the w3c cg has a “more structured process”. Issues are ignored, sometimes for years. Issues are closed without a documented process. The CG might develop a more structured process, but certainly it’s not close to that over the last 5 years. The FEPs are already alot better than this, but should strive to be on a par with WG deliverables.

1 Like
81

Sure. The CG has been dormant for a long while. For what it’s worth, that’s changing now, and adopting an issue processing procedure will be one of the first things the CG will decide on.

1 Like
82

2 posts were split to a new topic: Procedures of the W3C SocialCG

84

4 posts were split to a new topic: Difference of opinions on W3C SocialCG process

85

Please only use this thread to discuss the original topic as reflected by the title. Two different subjects being discussed here have been split into their own topics:

4 Likes
88

Deleted posts moved here