steve

steve, 3 days ago to fediverse

According to Federated Social Network Service/System (SNS) History, the term "Fediverse" was coined on 2012-05-25. Long before #ActivityPub... just sayin'.
https://codeberg.org/ddfon/federated-sns/src/branch/main/fediverse-history.markdown

steve, 16 days ago to fediverse

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.

steve, 29 days ago to fediverse

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?

steve, 2 months ago to fediverse

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.

steve, 2 months ago to fediverse

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, 2 months ago to fediverse

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?

steve, 3 months ago to fediverse

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

steve, 3 months ago to fediverse

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, 3 months ago to fediverse

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.

steve, 3 months ago to fediverse

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.

steve, 3 months ago to fediverse

@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.

steve, 4 months ago to fediverse

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. 🤯

steve, 4 months ago to fediverse

#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?

steve, 4 months ago to fediverse

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?

steve, 4 months ago to threads

If you're interested in #Threads #ActivityPub posts, here are the existing profiles to follow.
@0xjessel
@btsavage
@christophersu
@mosseri
@rklambo
@sblackst
@shubhankar_91
@tb_99999
@wongmjane

steve, 4 months ago to fediverse

I often see the "Robustness Principle" invoked when discussing ways to improve #ActivityPub interop. There's an IETF draft that discusses the negative consequences of this strategy. Instead, they suggest that "A community that takes an active role in the maintenance of protocols will no longer need to rely on the robustness principle to avoid interoperability issues." Sounds great to me.
https://intarchboard.github.io/draft-protocol-maintenance/draft-iab-protocol-maintenance.html#name-harmful-consequences-of-tol

steve, 5 months ago to fediverse

I just read an article that claimed local #ActivityPub interop testing is difficult because the spec requires HTTPS. The AP spec strongly recommends it for publicly facing URIs (a very good suggestion) but does not require it. Some developers implement servers with HTTPS-only endpoints and that indeed makes local testing more difficult and makes it more challenging to use reverse proxies with SSL termination. It would be nice if all servers allowed opt-in to HTTP endpoints for these purposes.

steve, 5 months ago to fediverse

One of the challenges with #ActivityPub targeting is that the targeting properties (to, cc, bto, bcc, and maybe audience) conflate inbox delivery, interaction authorization, notification policies, and visibility (and probably more). This is a broad range of somewhat orthogonal behaviors and the limited guidance in the specs for them only makes it more challenging for AP devs.

steve, 5 months ago to fediverse

It's a little confusing, but there is no base actor type/class in Activity Streams 2.0 (unlike Activity for activities). There are only some specific actor type URIs (as:Person, as:Service, etc.). An #ActivityPub actor is a restriction of an AS2 actor and required to have inbox and outbox properties, unlike an AS2 actor (which has no required properties). Both AP and AS2 actor data can exist in the same application and can be used for different purposes.

steve, 5 months ago to fediverse

#ActivityPub dev tip of the day: An inbox (or outbox) is not a queue. An inbox is reverse chronological (LIFO-ish) and maintains long-term references to items. A queue has FIFO behavior and items are dequeued/removed for processing. AP is difficult enough without equating the inbox concept with MQ middleware (which could be a useful internal implementation technique).

steve, 5 months ago to fediverse

An #ActivityPub developer recently asked if my AS2 JSON Schemas require the AS2 JSON-LD context in a message. The answer is no. The AS2 specification does not require the context in a message if it is sent using the correct AS2 media type. The server must treat the message as if the context is present. However, for interop, it’s a good practice to always include it. Mastodon requires it, for example.

https://github.com/steve-bate/fediverse-jsonschema

steve, 6 months ago to fediverse

#ActivityPub developers can process AP messages as JSON or as JSON-LD. The primary purpose of JSON-LD is RDF serialization. If you aren’t using RDF, you probably don’t want to use JSON-LD processing (expansion, flattening, ...). Even if you're using plain JSON processing, please provide a proper JSON-LD @context for JSON-LD processors. Watch for incorrect URI prefixes and blank nodes as potential issues in expanded message data. JSON-LD Playground can help with this.
https://json-ld.org/playground/

steve, 6 months ago to fediverse

This looks very interesting. The goal of ActivityPods 2.0 is Mastodon-compatible integration of #ActivityPub with Solid Pods. They call it Mastopods.
https://activitypods.org/blog/the-road-to-activitypods-2-0/

steve, 6 months ago to fediverse

If your application accepts POSTed json-ld documents (like #ActivityPub or LDN) and does json-ld processing (versus plain json processing), be aware that there are security risks. The linked issue identifies 5 potential attacks. The issue was raised for the Python rdflib library, but probably also applies to the default behavior of other libraries. Risk mitigation? Deny/accept lists for automatic context retrieval is one example.
https://github.com/RDFLib/rdflib/discussions/1543

steve, 6 months ago to fediverse

It can be difficult to understand the role of JSON-LD in #ActivityPub. I see criticisms that are based on the belief that JSON-LD is a schema language or a validation tool. It's not. It's an RDF serialization. There's a good online book, "Validating RDF" that discusses several tools (including JSON Schema) that can be used to constrain message shapes (define schema) and do validation based on those constraints.
http://book.validatingrdf.com/index.html