Newbie: Common FEDERATION support, privacy, DMs and other non-obvious things

ActivityPub
1

As someone who has only immersed myself in ActivityPub specs and source code for two months, I can start to see the basic common outlines of what AP servers do, and why therefore there is such a thing as the Fediverse. But it’s becoming more and more clear that AP is a garden with so many different flowers in it, each one with its own scents and colors.

I guess at the outset (back in 2016-17) the few applications then attempted to include a FEDERATION.md file explaining which activities each would support, any extensions to the AS vocabulary each would add, and some other details. I was only able to find three of these, for Zap, Tavern, and Mastodon. I guess current implementers don’t feel the need for it. But there is useful information in there. In Zap’s FEDERATION, for example:

The Zot permission system has years of historical use and is different than and the reverse of the typical ActivityPub project. We consider ‘Follow’ to be an anti-pattern which encourages pseudo anonymous stalking. A Follow activity by an actor on this project typically means the actor on this project will send activities to the recipient. It may also confer other permissions. Accept/Follow usually provides permission to receive content from the referenced actor, depending on their privacy settings.

It’s hard for someone new attempting to implement a server to figure out if there are any very commonly used assumptions about addressing, which core activities you really should support and which are not that important, etc.

Without having to dig through the source code of 5 to 10 of the biggest servers, I have a lot of questions about privacy and distribution. I have looked through FEPs and read some of the discussions here about the various ways to implement true “direct messages” and I guess some standards are becoming clearer there. But I guess the Fediverse will always be a place where each server can do what it wants (with the result being varying degrees of interoperability).

It seems to me that a user’s expectation of a level of privacy needs to be a global concern. So here’s one example of a question I don’t find trivial (maybe the answer is obvious): Do most servers implement the filtering of items in standard collections (“Outbox”, “Liked”, “Shares”) based on the contained objects’ “to”, etc, addresses, or are these in general considered public? The spec says these collections

MAY be filtered on privileges of an authenticated user or as appropriate when no authentication is given.

2 Likes
2

I think the confusion here might be in the way the spec is worded—you should never display non-public activities to in the outbox unless authentication is implemented. Unfortunately, consensus for the type and nature of that authentication wasn’t established before the spec was released, so it was left open for later extension and improvement. That’s why you’ll see references to authentication and authorization primarily left as MAYs in the spec, because it wasn’t certain at all whether authentication would be possible across different servers.

In fact, here is the language for the Outbox collection, which is even stronger:

The outbox stream contains activities the user has published, subject to the ability of the requestor to retrieve the activity (that is, the contents of the outbox are filtered by the permissions of the person reading it). If a user submits a request without Authorization the server should respond with all of the Public posts.

So you can see here that only public activities should be displayed. The other collections (likes, shares, following and followers) have the separate MAY language. The only one I could see that language being confusing for is likes and shares—I don’t think any responsible implementor would consider it optional to hide a private Announce from the shares collection, but because the spec doesn’t require you to implement authorization, it’s still a MAY to show them if the user is authorized.

Most (all?) existing implementations support HTTP Signatures for authentication, based on the publicKey property of the actor. However, probably only some implementations use that authentication for outbox requests. This is because the primary focus of implementation work has been on the server-to-server aspect of the protocol, which doesn’t necessarily rely on outboxes to function. Again though, even if Authorization isn’t implemented, that just means that only as:Public posts will be returned.

2 Likes
3

As a newcomer I can relate to this (on the history of implementations of Groups):

Ad-hoc Interoperability will likely further increase over time, and the ecosystem will become more unattractive for newcomers .

4

Thanks for the clarification. Here’s another Q: can an Update change the visibility of a previously address-restricted object? I guess it could.

5

That’s an interesting question. It comes down ultimately to how you interpret the “delivery” sections of the spec. I think it’s fair to say that by a strict and precise reading of the spec, the decision to add a post to a user’s inbox is made once the post is delivered to that inbox (or to the sharedInbox) by the originating server, and that subsequent updates to the to or cc property can’t retroactively change that delivery. But in practice I would expect most implementations would want to add support for Updates of that nature.

6

One more subtlety. Say I allow users to maintain their own arbitrary collections of objects. When a user posts an “Add” activity and references an object by its id (rather than the full content), what should control the visibility of that object to others–the original audience of the object (which could be obtained by dereferencing it); or just the audience specified in the “Add” activity; or a union of the two (as is specified to be done for a “Create” activity).

Unless the visibility of the original object is maintained, this is kind of like the situation where someone emails others with the contents of a letter that was presumed to be private by the author). But ultimately I guess social networks have no guarantee of privacy, unless messages are end-to-end encrypted.