If you're a #fedidev working on an #ActivityPub/Mastodon-compatible server, don't forget that the WebFinger JRD media type is "application/jrd+json" and not "application/json". The early @feditest test results show this is a common mistake.
It seems like the #ActivityPub Recommendation primarily focuses on behaviors related to received Activities, especially in an S2S federation context. Exceptions include inbox forwarding (7.1.2), shared inbox delivery (7.1.3), and broadcast of public messages to all known servers (7.1.3). However, for specific activities, like Delete, the behavior related to sending them is unspecified (e.g. which recipients should be included and so on). Am I missing something?
I see discussions about an #ActivityPub 2.0 version, but I feel like there has never even been a 1.0 version. It's subjective, but for me, a 1.0 version implies some degree of completeness and maturity in the product. The current Recommendation was released under time and political pressure with many compromises. It feels more like a 0.1 version and that’s fine. Except… it hasn’t evolved past that in the last 6 years.
If you were measuring performance of #ActivityPub servers (let’s say, delivery latency under load and active user scalability, to start) how would you propose doing it? What else would you measure? Are there any existing benchmarks?
@steve For delivery latency, i'd measure from the server finishing to process the request to create the item, to the last follower server receiving all the request bytes. Looking specifically for implementations that don't scale up properly with Shared Inbox Delivery, eg: with 10,000 followers on the same instance. And implementations that don't parallelize their deliveries, eg: serial deliver where one server can timeout & delay other deliveries.
Say you set the goal to be "a failed delivery is retried at least every 60 minutes". That's the metric you alert on. Not e.g. size-of-outbound-queue - the outbound queue might be large, but if you're still processing it frequently enough to meet the every-60-minutes goal that doesn't matter (from a user performance perspective).
The Activity Streams Question activity is puzzling. The word "question" can be used as a noun or a verb. As a noun, it can exist independently of posing the question to a subject. The AS2 spec classifies it as an IntransitiveActivity. However, the spec examples include no actor, which implies it's being used as a noun. It seems like there should be a (transitive) Activity like "Ask" with an object (Question) and a target (the thing being asked the question). #ActivityPub
Given it also applies to #ActivityPub, can someone explain the following “ActivityStreams 2.0” requirements? (Section 2.2) “(1) when an IRI that is not also a URI is given for dereferencing, it must be mapped to a URI using the steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as an "id" value, it must not be so mapped.” Isn’t an IRI given for dereferencing always an IRI serving as an “id” value for some Object? Maybe some examples would help to clarify it?
@thisismissem Yes, that what it seems to be say, but that doesn’t make sense to me. I’m wondering if the intent is that the “id” IRI is not converted to a URI when the Object is serialized into JSON-LD for transport? Or maybe it means that any software doing the dereferencing must do the IRI to URI conversion before making the request (with the receiving server doing the inverse URI -> IRI conversion for lookup)? However, those are wild guesses on my part.
According to Federated SNS history, first there was the "identiverse", then there was the "fediverse". And, of course, there's the "metaverse". Now there is the "agentverse"??? The latter reminds me of the actor(à la Carl Hewitt)/agent-oriented vision of #ActivityPub I sometimes see discussed, only blockchain-based. 🤔 https://fetch.ai/docs/concepts/agent-services/agentverse-intro
I’m beginning to wonder if the email mental model some people suggest for #ActivityPub is a serious hindrance to understanding the concept of a federated, decentralized social graph.
@steve is email the "right" mental abstraction, or is it just the most convenient?
Even during the advent of email, "to", "cc", and "bcc" seemed oddly outdated, but that's because it too, came from something before it.
Nowadays with fine-grained permissions and ACLs baked into a lot of the software we already use, stuffing it into a recipient list seems awkward at best.
AFAICT (and I could be wrong), the Activity Streams 2 data model was originally intended for social activity import/export and publication of activity descriptions via RSS/Atom. In this context, I think the generality and flexibility of the data model (and even JSON-LD) have some clear benefits. However, I also think that using that data model as a command language in the #ActivityPub protocol is more problematic and has resulted in many interoperability challenges.
If the #ActivityPub community effort to define problem domain-specific AP interop profiles proceeds past the discussion phase, some initial profile candidates are: microblogging, video sharing, image sharing, audio/music sharing, media review (books, movies, etc.), and event planning. Each of these has existing implementations and represents a specific AP use case. In the longer term, other profiles, like for forge federation, could be added as implementations evolve and mature.
@Brendanjones@smallcircles Yes, that would be one aspect of it. Ideally, it would include JSON Schema or LinkML definitions of the messages needed to support a specific community's interoperability requirements.
@helge It looks like your Fun Fediverse support tables are currently focused on microblogging implementations. Do you plan to expand that to other federated solution domains? If so, I recommend taking a look at FunkWhale's #ActivityPub implementation. It's different than the classic microblogging use case in several interesting ways.
The #ActivityPub sharedinbox is a strange concept. It's an inbox without an actor. I suppose one could think of it as being backed by an implicit, non-conformant (no outbox) actor-ish thing that routes messages to other inboxes. There's no requirement that there's zero or one sharedInbox per server. A server can have any number of them. You could have one per set of actors in a Group or Organization, for example. But then the sharedInbox would an Group/Org actor-specific inbox. 🤯
#ActivityPub developers... do you implement an actor (or actors) that provide server-level functionality other than resource fetching or a relay endpoint? Can they be followed? Do they process incoming activities? Is discovery of those actor URIs required by other servers? If so, what are the use cases?
@mariusor Interesting. So it’s a kind of anonymizing proxy for the people-related actors implementing the moderation actions? Will it also accept incoming activities or just proxy outgoing ones? Are the moderation actions federated outward using proxy Follow relationships or published to a known server list or …?
@steve it's not that well specified defined at the moment. :D
I haven't delved into this part of the code for quite some time, but if I recall correctly most of the logic resides in the client, not the server, so incoming activities can be accepted, but they probably won't have the desired side-effects.
If you're running your #ActivityPub based server on a home network behind a CDN, be aware that AP's key retrieval behavior will leak your home network address. Mitigate this risk with custom firewall configurations or running your server with a reverse-proxy/tunnel so no server ports are open on the home network (ngrok, Cloudflare Tunnels, etc.). Any other suggestions?