For years we've been using an alternate protocol between our own sites because ActivityPub wasn't capable of providing the services we require for federated communications. This is how we've supported things like nomadic identity long before the concept was even viable in ActivityPub. Now that I've got a usable framework for nomadic identity over ActivityPub, I went back and had a closer look at what else I might need to add to ActivityPub in order to finally put the Nomad protocol out to pasture.
I've mentioned transport encryption in the past; but that's only a big deal if you don't trust HTTPS security or your government. For true nomadic identity, we would also be sending sync packets so that your alternate identities are kept up to date with everything you do on other instances which share that identity. We'll also be offering a partially shared identity as mentioned in previous posts. This won't be a true clone but will instead be a way to link your various fediverse profiles in a cohesive way - like we do with our Fediverse Identity Manager. These are all pretty easy - just a 'Simple Matter Of Programming®'.
But I overlooked a real biggie. Permissions, permissions, permissions. A concept completely lacking in ActivityPub; and which can't be discussed rationally with other fediverse developers because folks raised on Twitter don't even understand the concept.
@mikedev Hey Mike, at the risk of sounding ignorant, is there a place where we can track your work and discussions on bringing the features of Nomadic Identity and permissions access to ActivityPub?
Are there Socialhub discussions we can follow, or a Git repo we ought to keep an eye on specifically?
I ask because one of my contacts is interested in sharing this work with the Nextcloud team.
For nomadic identity I'm just implementing FEP-ef61, and using a resolver on all nomadic objects so that they're backwards compatible with the existing fediverse.
I'm in the early phases of permissions, and my implementation has not yet been finalised, but it will no doubt consist of a new actor endpoint called 'permissions'. Fetching it with a signed request will return an unordered Collection of rights that I have granted you. The specific object representation of those rights is still up in the air, but I'll write something up once I settle on it. It has to be extensible so I'm currently thinking of using an array of URI like
That branch should be considered unstable and not deployable for the immediate future, but that's where I'm doing this and anybody is welcome to monitor the repo activity.
@mikedev so, I'm not sure what you mean by "permissions". Typically the authorization model for AP is pretty simple: the actor or attributedTo actor has full write permissions, and anyone in the addressees lists has read permissions and reaction permissions (reply, like, share, etc.). That does mean that it's hard to implement ideas liked shared collections, or a wiki-like text. I'd like to see those kinds of permissions defined more in the future. Is that what you're getting at?
This is exactly what I meant by folks raised on Twitter not understanding the concept. This isn't personal but I'll warn in advance that I'm going to be a bit harsh in my reply.
I have a series of permissions that I can apply to anybody and my server enforces them. Whether they can send me comments, whether they can see who all my connections are, whether they can send me direct messages, search my content on my site, or view my photos - and even whether they can upload photos to my albums and "administer my channel". We've currently got about 15 separate permissions, and if I don't grant you that permission, my server is not going to accept your request to do that thing. These are all things that my server can enforce. We don't offer any permissions we can't enforce such as whether you can search my posts on your own site or write comments. Sure you can write comments to my posts, but if I haven't given you comment permission, I'll never see them and they certainly aren't going to be shared with my folllowers. This is a completely different model of the fediverse and I've been telling you about it since 2010 and it's like talking to a brick wall. It's ok, I understand your point of view. Hope you can understand mine. I call it "consent based communications". And it's bloody important.
In our world a "follow" request doesn't mean that you can stalk anybody you want and send them obscene pictures and spam and see who all their friends are. I wrote a post about that a while back and called it rape culture, because that's exactly what it is. This isn't about you doing whatever you want and forcing me to respond if I don't like it. This is about me allowing you to do stuff in the first place. You should be granted permission to do any/all these things - or they simply aren't going to happen.
@mikedev permissions on ActivityPub is exciting and scary. Exciting because it paves the path for #ActivityPub to support serving groups with necessarily complicated formal relationships (eg work relationships).
Scary because permissions can be designed oh-so-wrong very easily. (eg the complicated history of permissions in Android and iOS). Balance between flexibility and usability is hard. The user's mental load is important for many reasons.
@travisfw@mikedev Presumably the implementation of permissions differs from the public facing representation. As long as the backend functionality exists then it's up to frontend devs to design a usable interface.
@mikedev I’ll agree 100% about the need for more granular permissions on the Fediverse.
So far, I’ve treated ActivityStreams as just one data representation (like HTML) not as the one core definition. I feel most permissions could/should exist somewhere separate from what’s published via ActivityPub.
Mike, could you expand on how you see permissions represented in ActivityPub itself? How does publishing this data benefit nomadic identity?
@mikedev Do you have FEP-ef61 actors already?
I'm still thinking about actor IDs. FEP-ef61 requires new IDs, so existing accounts have to be migrated somehow. I guess it is not an issue for you because you already have working migration mechanism?
We'll require a migration no matter what we do. We do have such mechanisms, but they're somewhat expensive. I'm keeping all of that work in another branch until it's ready for prime time and the migrations are fully integrated.
Add comment