ActivityPub: federation, gaps and what ships next

Sep 7, 2:00 PM·57 min·16 chapters

CWS1CSS2MB

0:00Chapter 1/16 · Panel discussion on ActivityPub preferences57:00

Overview

The panel examined the strengths and pain points of ActivityPub, announced a multi‑year Spritely grant to build demos that close identified gaps, and explored how the Fediverse can improve documentation, security, client‑server interoperability, and discoverability.

Key topics

Preferences on ActivityPub (likes/dislikes) – 
Spritely grant announcement and demo roadmap –  / 
Need for better community coordination on implementations – 
Documentation for Mastodon‑compatible profiles – 
Extending ActivityPub and allowing future extensions – 
End‑user benefits of federation – 
Unifying client‑to‑server and server‑to‑server protocols – 
Building a universal client & peer‑to‑peer suitability – 
Privacy, encryption, and private messaging concerns – 
Secure ActivityPub via object‑capability concepts – 
XMPP integration prospects – 
Federation‑wide search and recommender systems – 
Use of secondary streams in ActivityPub – 
Blockchain hype vs. practical decentralized social networks – 
Discoverability challenges and open search standards –

Decisions

Chris Webber will lead a multi‑year Spritely effort to create demos that address ActivityPub gaps and explore security hardening (, , ).
The community acknowledges the need for coordinated documentation, especially for Mastodon compatibility, but no concrete doc plan was finalized.

Next steps

Spritely demos: Chris to develop and release the planned demos over the next couple of years.
Community coordination: Participants to discuss mechanisms (e.g., working groups, shared repos) for agreeing on standard‑conform implementations.
Documentation: Explore creating a Mastodon‑compatible profile guide.
Security research: Investigate object‑capability approaches for a more secure ActivityPub protocol.
Federated features: Teams interested in search, recommendation, secondary streams, and discoverability to prototype solutions and share findings with the panel.

Speaker 1

So we have Elliot here, we have Chris, we have Matt, and we have Cory on stage.

And we'll just pass them the mic and see what happens.

Chris Webber

I guess the mic is being passed to the middle.

Hello everybody, how are you doing?

Yeah, preaching the end of the first day of FOSDOM, so everybody is probably a little

bit exhausted.

I'm Chris Webber, I'm one of the co-editors and co-authors of ActivityPub.

Just out of curiosity, how many people here are familiar with ActivityPub?

Raise your hand.

Okay.

You know, a good portion of the audience, not everyone.

Also how many people have looked at the ActivityPub specification?

Wow, that's like a lot of people for a specification.

So for those of you who aren't familiar, the, you know, talking about federation, the general

idea of federation is that we have different, you know, the same way that you can speak to

people on different email servers.

We want to do the same thing with the social web.

So there's no reason that Twitter or Facebook should control just, you know, those social

sites.

Anybody should be able to run their own servers and speak to each other.

And ActivityPub is just a protocol that describes how the different servers can talk to each

other.

So anyway, I said who I am.

I'm Chris Webber.

I'm going to pass it this way and then it'll wrap around like Mario too.

Hello.

Hi, everyone.

I'm Elliot.

Matt Baer

I'm the maintainer of a software called Thunk Whale, which is basically a GrooveShark/SunCloud

alternative working with ActivityPub and over-decentralized technologies.

Hi, everyone.

I'm Matt Baer.

Speaker 2

I'm working on a project called Write Freely that's basically a really simple blogging platform

that also integrates with ActivityPub.

Hello.

Corey Slepp

I am Corey Slepp.

I work on GoFed, which is a GoLang implementation of ActivityPub, a library, not an end user app.

Busy working getting V1 out, so I'm here on my individual capacity and I don't speak for

my employer.

Chris Webber

We'll just assume that goes for everyone.

So I guess we're freestyling this one a little bit, partly because of my fault because I've

been very overloaded.

So I'm just going to start things out by saying to the other panelists on the panel, what made

you interested in picking up ActivityPub specifically?

Matt Baer

For me, it was because it was really easy to understand, I think.

And also because most of the protocols I've seen were focused on social stuff.

And ActivityPub in Funquale, it's used not at all for user interaction, but more for server

to server interaction.

Because Funquale use ActivityPub to exchange music from servers to servers.

And ActivityPub helped me do that and I don't know if I could have to do that with something

else without reinventing too much things.

Yeah.

Speaker 2

For me, I was just really attracted to how easy it was to start up communities that could,

that had their own flavors to them and could still communicate.

I started running a Mastodon instance and that really got me, you know, just seeing how the

type of people that were coming on board and seeing how everyone interacted and how the

software worked.

How you could have similar, you know, music or video or just small posts and they all come

into one place.

So I thought, you know, that would be perfect to build on.

I'd like to add to it.

Corey Slepp

For me, GoFed is kind of a personal story.

I immigrated to Europe in the winter of 2017 and found integration difficult.

So I started a side project, which is what it's grown into.

And I've had a couple of users.

I think WriteFreely is one of them.

And it's been amazing seeing the ecosystem come to be what it is.

And I've learned quite a lot along the way.

What the spec is, what the spec isn't.

What it is meant to cover.

What it is meant to not cover.

And where the state of the world is now.

Chris Webber

Before I throw on the next question, I just wanted to say that how much I appreciated the

previous talk, actually, and how much I agree that the process of federation and decentralization

is a political act.

And that our real goal for me, and one of the reasons I got involved in standardizing things,

is about distributing power.

And so I think that it's important to keep in mind with our work.

But anyway, I have one more question that I'd like to ask.

And then either you all can ask questions, or even better, the audience can ask questions.

So, and I have an answer to this for myself, but I'm going to wait last to say it.

What is one thing you've liked about ActivityPub, and what's one thing you don't like/hate?

Speaker 1

Anybody want to go first?

I like ActivityPub because, so, I like it for what it does.

Corey Slepp

And what it does is it gets very distinct applications to agree on a way to communicate.

I don't like the way people have taken what is lacking out of ActivityPub sometimes as an excuse

to downplay it and dismiss it.

It's meant to grow.

It's meant to be iterated upon.

And some people look at it as it is now and say, this is it.

This is how it's meant to be for the rest of the world, for the end of time.

It can't grow.

ActivityPub is dead in the water.

I fundamentally disagree with that claim.

Whew.

I agree.

Sorry.

Speaker 1

If you want to ask questions, we need this one.

Oh.

Okay.

Yeah.

Thanks.

Can you hear me?

Matt Baer

One thing I really liked is that it's made of small pieces.

So you can pick WebFinger or ActivityStreams and it's conceptually easy to get.

And for Funquail, there were many types of objects that were already available, like audio,

listen, and things like that.

So I could just pick things and it worked.

And one thing I didn't like was the fact that some things were not specified enough, like the HTTP signatures thing or all the authentication workflow, basically.

Speaker 2

Yeah, I agree with both of those things, basically.

I like being able to just pick and choose which types you're going to send around and pretty much they'll be, you know, understood.

And the hardest part was the implementation, just going from the spec.

I started reading through it, did not finish it.

And it was kind of open-ended enough to where it was hard.

So luckily, our panelist on the end there was around building his own, you know, doing the dirty work.

So that's pretty much why I could end up implementing it.

Great.

Chris Webber

So the thing that I like is that ActivityPub has a good conceptual foundation for it, which is the actor model, actually.

Everything is an actor.

Well, not all things are actors.

Things that have inboxes are actors.

And they send messages to each other, which is a pretty well understood concept.

And the whole idea of the inbox and outbox, I think, are pretty simple.

I wish people would pick up the client to server protocol, by the way.

We could.

That'd be really great.

But I think -- and I think that having that foundational understanding, even though many things are an actor model,

understanding that your implementation is an actor model allowed the specification to be much cleaner.

What I don't like -- it sounds like we're achieving some consensus on this panel, actually.

We did leave some gaps in the spec, and that's correct.

And the reason for that is we had a few years of a specified timeline.

We got several extensions.

And at the time that we moved to specification, there were certain things that were not agreed upon in the community.

For example, how do you do authorization and authentication is probably the biggest complaint that people bring up all the time.

And it was -- and we instead put suggestions and actually pointed at community suggestions in the specification.

And that's because if we did it at that time and we implemented it and we threw it in there, we would have just suggested something that was probably wrong.

And so we decided to deliver a specification with the parts that we knew were right in general, with one big exception, which is shared in box,

which I think we did something wrong with that at the end in trying to help Mastodon get it out the door quickly.

But I think that -- and part of my goal over the next couple years -- by the way, it was just announced a couple days ago,

I got a grant from Samsung's Stack Zero thing, and I'm going to be spending the next couple years on a project called Spritely

that develops demos on how we can fill in those gaps to make the federated social web much more resilient.

And that includes things like what happens when a server goes down and all that content disappears,

and then nobody can interact with it anymore.

I just put out the first demo that begins to give an answer to that this week called Gollum.

And so that's going to be my next couple years is trying to develop demos that piece by piece show how we can bring

the Fediverse to the next level, even closer to the kind of things that peer-to-peer networks provide.

Anyway, with that, I'd like to open it up to the audience, unless -- do any of you --

have a question that you'd like to move forward on?

All right. I bet some people have questions. We have at least one.

Speaker 1

While I implemented ActivityPub in our project, it was really easy implementing the parts that already had been implemented

by Mastodon, Pleroma, and so on, and to see how they did make it.

But our project is fairly complicated, so we have a much larger thing to implement.

And then I came to a point where I was unsure how to implement this or that.

And so I guess it would be important to have some kind of coordination, some kind of discussion for me.

I don't know where all developers or most developers should agree upon how to make things.

So have you any suggestions how to do this? Because I don't want to develop things that would be standard-conform,

not only for our software, but something that all would implement that way or in another way.

Chris Webber

Okay. So that we agree upon this.

Yep. Yep. My bad. So we actually -- I'm co-chair of a group called the Social Web Community Group,

which is a W3C group that anybody can join, unlike the working groups that are set up to set out standards.

This is a space to incubate ideas and figure out the next generation of things that have not been well-defined.

You're welcome to join. Anyone in this audience is welcome and encouraged to join.

I will say that I have not been doing a great job as community leader, aside from showing up to meetings,

which I don't always do, and I would like to do better.

And one of the other problems is that we have a whole bunch of issues, and I haven't been getting through them very well.

But in one of the most recent meetings -- and I haven't put it on the activitypubs.rock site.

Sorry, sorry. I know I'm very terrible about these things.

Someone did set up -- and I forget the name of it.

It was used to theoretically coordinate this panel at the end.

There is a forum -- what was the name of it?

Speaker 1

Social Hub. What?

Social Hub. Social Hub. That network.

Chris Webber

Right. Social Hub. That network. That's going to be a place for people to communicate.

We also have an IRC channel on the W3C thing, but that's not -- it's kind of disconnected.

But I think that the socialhub.network could help out a lot.

But do any of you all have comments?

Matt Baer

No. About Social Hub network, yeah, it's really interesting.

I'm using it for Funk Whale, and if more projects came and use it all together, it would be interesting to coordinate on developments and fill the gaps in the specs or things like that.

Speaker 1

Sorry, I have one last thing to say.

Corey Slepp

This is an area I really want to explore once I feel good about the GoFed library.

I've posted a blog post about this, exploring an idea where you take an ActivityPub extension and embed it into ActivityPub itself, so your extension to ActivityPub can federate,

which would enable decentralized authorities managing their own ActivityPub extensions, but since it's federated data, a centralized repository.

So you don't have the problem of you have to know all these different projects and their extensions.

It's on the Fedverse.

However, you don't have the problem of a centralized authority where it's, you know, David versus Goliath kind of situations and acrimony and power struggles.

Each person can manage their own or group can manage their own ActivityPub extensions.

So it's an idea I really want to explore.

Speaker 1

We should talk more after this panel.

Other questions?

Yes.

Ready.

Nope.

Right there.

Speaker 1

So you said in your introduction you learned, like, what ActivityPub is and what it's not.

So can you elaborate on that, especially on what it's not?

Maybe all of you can, like, like, your own idea what, like, what people might interpret.

Oh, yeah, I'm going to use ActivityPub for my thing and it's going to be awesome, but maybe there are actually some cases where you shouldn't use it.

Corey Slepp

Okay, so this goes to, like, a philosophy I've been developing over a year and I'm not sure if it's what was intended by the social working group.

You know, I read the notes, but I really view ActivityPub as, you know, as two protocols in one, there's a client to server and server to server.

That's how it's divided.

But I view it as two protocols in a different sense.

I view ActivityPub as a physical byte transmission protocol, getting bytes from A to B.

I also view it as a very lightweight social networking application layer on top of it.

So it's one protocol with both a transmission layer and a little bit of an application layer.

And what kind of helped me realize this were folks at, like, the ForgeFed effort and the ValueFlows effort.

These are people who want to extend ActivityStream's vocabularies into other domains, like the economic and the CodeForge domains.

And it made me realize that ActivityPub had built in this social media lightweight vocabulary bias into it.

So that kind of fuels my perspective on why we need to iterate on this to allow these other kinds of – I call them flavors of networks coexisting with each other.

So you can have your CodeForge living on its own if you want.

But if you want to build a co-op around the CodeForge, then maybe you also want the economic network as well.

Speaker 1

Did that answer your question?

Chris Webber

I have two things from that.

One of them is what ActivityPub – so I'm kind of twisting your question a little bit into what ActivityPub could be.

And also – so there have been some perspectives.

So one of the criticisms that ActivityPub has gotten, actually, was that some people don't like that we allow for extensions, for instance, actually.

Because when you allow for extensions, that means by default there's going to be things you don't understand, right?

Because somebody will have used – now we have a way of doing extensions.

But let's just ignore what that way is and ask, should extensions be allowed?

And there's a famous post by one of the Diaspora developers that says, basically, no, you should bake in everything that your world is going to be at standards time, and then that's it.

And I never got around to blogging about my response to that, but to me that doesn't – I don't see how we could – I felt like if I had tried to write in all of the types that were possible

in ActivityStreams and ActivityPub at the time that we put it out, it would be very egotistical to me to believe that I would know what the future was going to be.

So for instance, maybe the future was going to involve – there's a lot of interest in having virtual spaces, right?

Maybe you put on a helmet and you walk around somebody's virtual reality thing in some sort of VR helmet, right?

You know, we have image and video. The future may involve that type of thing.

It certainly doesn't exist well enough to us to specify at the time that ActivityStreams and ActivityPub were released.

I can't assume that I know what the needs of that community are going to be, and I don't want to lock them out.

So it's an open world system as opposed to a closed world system, and those are two different ways of handling things.

And I think that – so I stand by that decision. I think there are ways that we can make extensions easier, and then we should talk about that.

But I think that the other thing that I'd like to say – I'm sorry, I feel like I'm monopolizing this, but I'm going to say one other thing – quick anyway.

The other thing that I was – oh, I lost it. I'll come back to it later.

Do you have anything, or do you want to move to the next question?

Speaker 2

Yeah, I would just say, as far as today, you know, especially, you know, there are a lot of different applications.

WriteFreely is one of the, like, more lightweight implementers of ActivityPub, and that's – that was just a design decision.

So that's kind of how, you know, there's definitely the protocol side, and it can do a lot, and it does have a bit of that application layer.

But it's really – if you need it, then, you know, I think it takes a lot of conscious thought about, okay, is this actually going to add to the product,

or is this kind of something that we don't even need?

Speaker 1

So, let's just –

Any more questions?

Oh, yeah.

Oh, sorry.

Wait.

Oh, yeah.

If an answer to my question is out of scope for the – for here, please say so.

Hello.

I have no personal experience with social media.

I've seen websites, but I never used it, and I dislike centralizations.

I would like to get into federated systems.

And so I have some difficulty imagining what the ActivityPub accomplishes, what kind of information is sent out,

when you give an end-user benefit of the federation between different platforms.

Okay.

Chris Webber

What would you say – I'll – I've got too many opinions on this.

I'm going to hand this off to one of you.

Speaker 1

What is the end-user benefit of federation?

Matt Baer

For Funquail, our use case is to have people sharing music, and creators sharing their music publicly,

and to have people commenting on music, and sharing people with – sharing music with their followers,

and stuff like that.

So, maybe that answers your question.

Because you could do that on any server, interacting with any other server, any other user, transparently.

Speaker 1

Do you have any of you else?

No, no.

I'll let you.

Oh.

Chris Webber

I really wanted to talk about the thing that I just remembered was in part for the other question.

So –

Do you want me to –

I can elaborate more.

Corey Slepp

It's allowed really cool interactions where you can have a microblogging site like Pleroma or Mastodon,

and have its users sharing, you know, their thoughts.

And then as well, with Peertube, for example, someone uploading videos, whether it's video blogging,

or whether it's, you know, instructional videos, and that will pop up in a Mastodon feed, Pleroma feed.

PixelFed as well, I think, just launched with lots and lots of pictures, beautiful pictures.

And so you're able to get those as well on your Mastodon feed.

So it allows these users, if they want – and this is an open problem – to sign up for these different services,

and have the experience they want consuming media, different kinds of media.

Speaker 1

And if I want to use it, it's a precondition that I have an account on each of those services.

Chris Webber

Ah, this ties in directly with what I wanted to say.

Okay.

So the thing I forgot that I wanted to talk about was the client-to-server and server-to-server protocol,

and why both of those exist, and how it ties in directly to this, actually.

So client-to-server and server-to-server.

Curiously, the client-to-server thing – so actually towards the end of the activity pub specification part,

the end of the social working group, we were running out of time, and it wasn't clear if we'd get the federated stuff done.

And Evan Prodromo, who's really responsible for a lot of activity pub's design and his predecessor OSTATUS,

said, "We should just release the client-to-server specification and not the server-to-server."

And I said, "No, I'm quitting the group if we don't get out server-to-server."

And we did get it out, and thankfully it was Mastodon picking up that allowed us to actually get that amount of momentum.

But there was a weird thing that happened.

We thought that one of the reasons why we would push out the client-to-server instead of the server-to-server

was that it's such an easier protocol, actually.

And then weirdly, I'm getting messages saying,

"Oh, the reason the client-to-server-to-server thing is not implemented is that it's much harder."

Like, what?

So it's almost the same protocol.

And there's an interesting world that opens up if we took client-to-server and server-to-server seriously.

Because it's almost the same protocol design-wise.

And if we took this seriously, it meant that you could use Mastodon's interface to talk to Peertube and Peertube's interface to talk to, you know, Funk Whale or anything like that.

But the way that the Fediverse is currently designed is actually really bizarre to me.

It has been to encourage each one of the projects that has come out has wanted to brand themselves as, like, the activity pub server for this.

And, like, it's cool that, like, these different things are happening.

And maybe that actually motivates developers.

And I'm sure you all have comments on this, you know, to be able to do that type of thing.

But to me, you know, so my friend Sebastian and I were just talking about this.

And one of the, you know, there are a bunch of people who are currently leaving Google+ who are really disappointed.

Because one of the things that Google+ did for them is that it actually was trying to take seriously that you could host a whole bunch of different media types on it.

So I don't see why we shouldn't try to pursue this vision of, you know, you are able to swap out any client for any server.

So I'm curious what my fellow panelists have about that idea.

Oh, and the reason that that's an answer to your question is that you wouldn't need five different accounts.

Speaker 1

Yeah, indeed.

Matt Baer

For me, I think one reason is that it's really hard to design a client that would work with any server.

Because for Funk Whale, the main use case is to listen to music.

And for Mastodon is to share toots and browse the feed.

And those are simply not the same use cases.

So if you wanted to build a client that would do all of this, it would be a huge beast and maybe with a bad user experience.

But that's an hypothesis.

I don't know.

Speaker 2

This is actually somewhere I've been thinking as well.

And maybe it's what you're saying.

I don't know.

I think we're like accidentally on the same wavelength because I've been imagining it to where you would essentially have your Mastodon account, for example.

But then you would use Funk Whale to post to, like through the client to server, send it to Mastodon or something.

So that's kind of where I've been going.

And in addition to the Write Freely side, the actual producing content, I'm working on the reading side.

So, called Read As.

And that's basically just a nicely, basically a feed reader except built on ActivityPub.

And using that to, again, you wouldn't have to create an account, but having it integrate with Write Freely to where you have these kind of these two sides where you're subscribed to all these people in the Fediverse, you're receiving their posts.

And if you want to curate some of that for other people to read, you just boost it.

And that ends up going to your Mastodon account or whatever, or your blog or wherever else in the Fediverse that you're kind of connected to.

So that's, I've kind of been thinking about those lines.

Speaker 1

So, my question is, I don't have deep knowledge of ActivityPub.

But from the information I got in my brief investigation of it, my feeling has been that the concept like server and client, stuff like this, really are wired into the protocol.

And that it would not be suitable for, for example, a peer-to-peer solution.

And because, for example, the assumption that the domain name is the way to reach the other server and so on.

While, for example, in my world, it's more like you have a cryptographic idea and that's the way to find the other.

Right.

I would like to know if my impression is wrong or if it's like that.

No, you're right.

Chris Webber

But there's no reason that it actually has to be the case in my view.

The, I actually think that there is no, so you're right.

I actually think that one of the weird things that happened, the current, one of the reasons why I think the current generation of the Fediverse.

And I have ideas on how to be able to do this with ActivityPod, but maybe we should actually talk.

You know, for instance, let's assume that you just actually, why should your client and server not be the same thing?

A lot of it has to do with the current assumption that everybody needs to run a server that exists somewhere else.

Probably all hosted at Amazon.

Uh, um, and you're like, haray, I've decentralized things, right?

And, uh, um, as opposed to, you know, home hosting or even just on the machine that you're actually on.

And it's a weird thing that we've developed in this mindset where we've given up on the idea of your personal computer being a very active agent in the system,

which was much stronger of an idea and peer to peer systems.

Uh, this, and, uh, um, and I think that a large portion of the reason for this is that a number of interests, a number of things happened at once.

One, Web 2.0 happened and everybody assumed they needed to run a server.

Uh, two, ISPs, uh, IPv4 started to run out of spaces and we started to get more NATs and, uh, ISPs actually started to put in their terms of service that you can't self-host a server, right?

Three, uh, um, peer-to-peer networks became associated with file sharing and specifically file sharing of pirated content, right?

When in reality there's no reason that peer-to-peer services can't be used for all sorts of other things.

So I completely agree with you that, um, this is something we should be exploring and the separation between it.

So technically nobody's using the client-to-server protocol anyway, so it doesn't really matter.

But, uh, um, but the server-to-server protocol, there's no reason if I spin up a, um, a Tor Onion service for ActivityPub and host it on my machine that's right there.

Aside from the live-ness problem, there's no reason that I can't actually send a message, um, to another person who's hosting an ActivityPub service over a Tor Onion service that's just running on their own local machine.

And, um, another reason for that I think has to do with, um, a complicated topic called Zuko's Triangle, uh, and the way that domain names come into that.

But I feel like that's a long topic, and I'll be exploring it with Sprightly, and maybe you and I should talk more.

Uh, do either of you want to, any of you want to discuss it, or should we do next question?

Next question.

Speaker 1

Yes, uh, one thing I like about ActivityPub is that it does everything that Ostatus did.

I'm from GnuSocial, uh, and, uh, the thing I dislike, uh, sort of, about ActivityPub is that it tries to sort of portray an image of, uh, of, well, serving private content in some way, or like ACLs and stuff.

Like, there's the notion of, uh, of a private message, or a direct message, or whatever it's called.

Uh, I think it's, somewhere it says explicitly that the spec doesn't have the scope of, uh, like, preserving privacy, or, or, like, guaranteeing the end-to-end encryption, or whatever.

Like, like, there's no specific, it's explicit in the specification, I remember.

Okay.

Uh, and, yeah, like, the, I'm thinking, considering the last talk, that, like, we should be, uh, open about how political code is, and, like, maybe specifications as well.

Like, maybe we should say that, like, this has nothing to do with private messages, or, otherwise, we have a huge problem of, like, solving federation, where everyone have their different scope and sense of privacy, essentially.

Activity.

Any comments about that?

Yeah.

Chris Webber

ActivityPub can absolutely do private messages, but the premier application that took off and ran with it, um, even picked it up partly for that reason, but, um, and this is one of the reasons why I say shared inbox was a mistake, actually.

Um, shared inbox moves from the idea that you're sending a message directly to another entity, directly to that entity's index, and instead assumes that you start routing

things based off of the server that you're sending to is understanding of the addresses that are coming in.

Uh, and that's a big problem.

Um, ActivityPub, as it's designed, is, um, we'll state, well, let's go in a couple approximations.

First one, if you go with the ActivityPub spec, and let's ignore shared inbox, even with shared inboxes as semi-true, it's as secure as email.

Right?

As much as I can send an- I, and in fact, Evan Prodromo designed it specifically influenced by email in that it has email-like addressing where you do to and blah, blah, blah, and you post directly to a specific user's inbox.

And if you implemented your server the same way that many mail servers do, where it ends up very much so in a specific user's inbox, then it would absolutely be direct messages as secure as email.

Right?

But now maybe you're talking about end-to-end encryption.

Right?

So, um, end-to-end encryption, the reason why we might want that is that a server, um, you have to trust your administrator to not snoop on your stuff.

And that's the same thing in email.

The same reason we have that thing.

And you'll notice how well email is doing with the end-to-end encryption thing, which is pretty bad.

You know, and, um, and, uh, I'll, I'll finish this and then I'll get back to you.

Uh, the, uh, um, and, uh, there are things like OMEMO and things like that that we could observe.

We actually had an issue in activity stream as, and I think, or activity pub, and I think it still exists about how we could do end-to-end encryption.

But, if we instead moved over to the fellow who's disappeared, who was sitting over there's, uh, comment about more peer-to-peer delivery, where we're doing direct messages between two different people's home computers, this entirely disappears.

Um, if the server-to-server transmission is from my TorOnion service on my, the machine that's running on my local machine, and I send the message directly to your inbox, directly on that machine, there is no man in the middle of an administrator.

Um, and there are ways to be able to move forward with that, and that's one of the things I'll be exploring as brightly.

But anyway, you've raised your hand again, so what was the follow-up?

Speaker 1

Uh, well, I don't have the microphone.

I was thinking more like the, uh, if it's meant for a social web, then it's, it also has features that are essentially, like, private domains which should just simply not federate.

So, like, in a federated environment, you will always have the issue of everything being up, depending on the server policies.

Chris Webber

Um, the, the question, the question slash statement was, uh, uh, in a, in a, uh, in a federated server environment, you always have the problem of the server basically sending things around from place to place.

Um, if you take the activity pub serious, uh, spec seriously at its most core of people sending things from inbox to inbox, it's very clear and direct exactly which messages get posted exactly to which inboxes.

When you start to get into attaching the, the public inbox or followers, things get more complicated.

The original version of activity pub, you would still post, except for to the, the public inbox that we had and then removed, you would still post directly to each followers individual inbox.

The shared inbox that we then discussed later would actually, uh, as a compromise when we were talking to Mastodon's folks, would actually have even still with that one for the non-public posts, anything that was not explicitly directed to public, you would actually, the intermediate one that we discussed in them was rejected.

You would actually deliver still to the shared inbox thing, and you would deliver a header of explicitly every single person that was going to be.

The receiving server would not inference who it was going to be distributing things to.

It would be explicitly distributed to these specific groups.

Um, that didn't happen partly because the response from Mastodon, which I, I, I said, okay, that makes sense, and I moved forward with at the time, and then later regretted, was, um, but we already have the information on our side

of who the followers are, so we can more efficiently distribute it without that header.

I think that was a big mistake, and actually violates the possibility of ActivityPub being very secure from an object capability perspective.

There are no ACLs in ActivityPub, by the way, and there shouldn't be, but people have discussed it possibly adding them.

Um, and this is one of the things I'm going to be exploring with Spritely, is how to make ActivityPub into a very secure protocol developed from object capability security literature.

Um, so anyway, that's my response. It was kind of long, I'm sorry.

Corey Slepp

Uh, if you're more interested in following along, someone who's pursuing this, LightPub, and, uh, a Pleroma developer named Canini is looking heavily into this area.

Speaker 1

Uh, next question. Yes. So, more to, uh, back to philosophy and economics. Uh, popular microblogging platforms, I heard, uh, are, uh, Twitter and Instagram.

Will they, uh, adjust for compliance?

Oh, will they pick up ActivityPub?

Or otherwise, what are, what, what reactions come from, from these, uh, kind, that category of, uh, providers of microblogging?

Chris Webber

Right. Will Twitter or Facebook ever, uh, pick it up, or will they even notice, right?

I'm sure they've noticed a little, but they clearly don't care too much.

Um, partly because we haven't really hit their radar on the level of success, I think.

Um, I mean, we've got a couple million users now, but it's not really enough to really worry of Facebook or Twitter.

Uh, I, I think you brought up regulation, like whether or not a regulative organization might force them to federate or something like that.

I think that would be really interesting and I think very unlikely to happen.

Uh, um, but anyway, uh, I think they're kind of ignoring us partly because I wrote in a blog post, um, one of the reasons that the big players, I think, haven't actually, um, had to really fight us in any way is that we tend to spend a lot of time fighting with each other.

And they don't, and we do that work for them.

So I'd like to do less of that, more collaborating.

Um, but anyway, I, I have very little hopes that, um, organizations whose profit model is entirely based around them being the walled garden of your, uh, um, of your content are going to be interested in picking up, uh, the Fediverse, basically.

Hi.

Speaker 1

So, um, first, some comments.

So, I absolutely love the fact that it's based around an activity operating on objects.

That's absolutely great.

I don't really like the fact that it's using JSON-LD, uh, to do things like, uh, sometimes I'm going to be, uh, list, sometimes I'm going to be, uh, string, sometimes it's going to be this, sometimes it's going to be that.

And, um, um, I'm, specifically I was looking at GoFed and that, that, I mean, you, you had to generate so much code, uh, that was killing my VPS when I was trying to build GoFed.

So, I really don't like that aspect.

I wish there was a better schema.

Now, uh, right, another comment.

I really like WebFinger and I wish, uh, that in the social aspect of it, it was more clearly specified that WebFinger is a nice thing to look up.

Email-like, uh, identifiers.

Actual question.

Have you looked into, uh, federating, sorry, cooperating with, uh, uh, XMPP Standards Foundation specifically to, uh, replace the, uh, microblogging specification or something like that?

Did, did you get in touch with them?

Because, uh, that thing is based around, uh, Atom, but not even like, uh, uh, or Status used it slightly differently, slightly incompatible, and probably not really, uh, trivially, uh, interoperable.

So, is there any work, uh, interacting with them?

Chris Webber

XMPP is awesome, and it was my first federated love.

Uh, so first I want to say that.

Uh, and more people should run XMPP.

I hate the fact that XMPP is kind of dying.

And my buddy list is very small.

Um, and I blame partly large corporations picking up XMPP and dropping it, in fact, which could happen to the Fediverse if, you know, Facebook or Google or whatever did pick it up.

Um, did we talk to them?

I have talked with them a number of times.

Uh, uh, um, what time is it left?

How much?

Fifteen minutes left?

Oh, that's not bad.

Uh, uh, the, uh, um, uh, activity pub.

I actually asked Evan Podromo early on, why didn't we just do all this stuff over XMPP?

And he said, well, if it could be done over XMPP, then maybe I'd be interested.

Several social attempts have been done for XMPP, and nobody agrees on whether or not you represent each,

uh, you represent each user individually or if the server, um, is doing things.

And now there's maybe the standard which didn't exist with the time we started.

Yeah, um, and, uh, uh, but I think that, um, part of the other reason for it is that activity pub is a web protocol taking the web protocol as being a web protocol very seriously.

It's entirely based on get and post, right?

And XMPP isn't that.

But XMPP is pretty awesome in some other ways, right?

Um, the, uh, you're going, eh, but, uh, um, but I, I've never seen.

Yeah.

Speaker 1

It's a specific, uh, set for PubSub that can do this and there's even a personal, like, um, micro-logging, sub-specification of it and so on and so on.

So, it can be mapped if it's, if they looked at anything remotely similar.

Chris Webber

Um, it, it can be mapped if you kind of squint your eyes and you figure out how to, and you intentionally make that decision, right?

Um, but it doesn't, it's not fundamentally a web protocol, right?

It's not fundamentally the way that activity pub is.

Um, I'm going to backtrack, make a comment on your last one about WebFinger.

A lot of people would like to see WebFinger officially in activity pub and it's not done intentionally for a reason.

Uh, and let me be very clear about why that is.

In fact, I, I think it's a shame that the way that WebFinger is being handled is not with the best way that it could be being handled in activity pub.

Which is to use the ACCT colon URI, um, form of WebFinger.

Because we use URIs for everything and that would be the best way to do it.

And actually that's perfectly compatible with activity pub spec and that's not how it ended up shaking out.

Basically because of the way that implementers were already using WebFinger.

Um, the, uh, um, however, the reason why we're not using WebFinger specifically was, um, the same reason why HTTPS is not actually mandated in the specification.

Despite everybody being like HTTPS, how else is it going to be secure?

The demo that I gave of how did you securely transmitting things over, um, a peer to peer network would not be possible in the way that I did it.

In a way that can be offline if we only did HTTPS.

And you will always have the centralization of DNS.

Always.

And there's an, um, if we require WebFinger.

And actually that's one of the biggest reasons I'm, I'm going to argue and that we'll get into more.

With the Spritely papers about why, uh, federated social web things are so hard to roll out.

Is partly our reliance on DNS and SSL security authorities.

If you imagine instead, uh, Bob at 200charactersofgarbage.onion.

Speaker 1

Nobody could address that guy.

Right?

Um, there is a solution.

Chris Webber

It's called pet names and we'll get into it more throughout the Spritely project.

Um, as for the other one, I want to hand it over to this guy who worked on GoFed.

And then I have comments as well, probably in response to himself.

Speaker 1

Um, we still have three questions to go.

Okay.

Um, yeah.

Let's let him respond.

And then I just won't respond.

Okay.

Just, just for the GoFed part.

Corey Slepp

V1, you can compile in Raspberry Pi 3.

So.

Okay.

Next question.

Hey.

Speaker 1

So we're from Dublin City University and are working on a social blogging platform using

ActivityPub.

Wow.

And we are worried that, uh, a federated social system is more susceptible to the problem of

echo chambers.

Uh huh.

And so we're working on a few extra spec features to try and remedy this.

And generally increase engagement across the Federation.

And we were just wondering if anyone had any advice or opinions or experience in implementing

searching across, like, the Federation, and also in, like, recommender systems in a federated

social system.

Chris Webber

You've got at least one person over there who is Arne, who you should talk to, who works

on this stuff with Freenet.

Um, I'm going to hold back from commenting.

Anybody else?

Speaker 1

I just want to say, as implemented currently, uh, Mastodon Pleroma tend to be very account-centric

with discoverability.

Corey Slepp

And there's no reason it needs to be account-centric discoverability.

Um, I was discussing before with some other folks interested that it could be a server-to-server

discoverability.

Uh, this discoverability problem has not been solved at all.

Um, so if you discover, hey, doing server-to-server wholesale discovery is the way to go, I'd definitely

be interested in following your work.

Speaker 1

Um, uh, there is funding for, uh, discoverability, uh, if you didn't get the, the word yet, uh,

and then let dot NL slash discovery, there is a 5.6 million euro over the next three years.

No strings attached for free software projects.

And this is part of the thing that can be funded.

Awesome.

So basically, um, if you do a recommendation, be very, very, very careful about spam.

Um, I'm release manager of the Freenet project and we have some, um, spam defense in there which

does not rely on any centralized service.

But it's, uh, problem which can really easily go bad and which is not trivial to solve.

I have some math lying around which shows that we can actually scale it up to the million

or billion scale if we, um, accept that there is no global visibility.

That visibility goes only over, um, connections between people.

And it should be possible to map it to, um, non-Freenet stuff.

And Freenet stuff basically it's, um, that there's a shared database which you can access

where you can have anonymous accounts.

And this has to be somehow mapped, uh, on the federation.

But then, um, I, maybe I can give Christopher, um, the address of some, uh, reference for that

so he can put, uh, paste it around in the right discussion forum.

Chris Webber

Let's, let's, let's chat more.

Let's, let's distribute these ideas.

Yeah.

Hi.

Speaker 1

Yeah, I just, uh, wanted to make a bit of a reaction to your quick dismissal of, uh,

the possibility of, uh, uh, cooperation, uh, implementing activity pub.

Because, I mean, no one thought Microsoft would buy GitHub, uh, that long.

So I think dismissing it is, uh, is not a good idea.

It's really about addressing it.

And, um, maybe there's no technical solution to that.

Maybe it's an identity solution.

That's fair.

That's true.

By the way, great talk.

Chris Webber

Uh, uh, the, uh, um, I agree.

Uh, and actually it's something we should be careful about because of what we've seen happen

with XMPP and email as big players pick it up and then decide that they're the only players

in the space or lose interest.

Speaker 1

I think having decentralized authorities can really help with distributing the power.

Corey Slepp

Again, thank you for your excellent talk.

Speaker 1

Hey, so I have a question for everyone but Chris.

Uh, so the implementers, uh, so there's a part of activity pub that talks about, uh, streams

and it's basically looks like no one really uses that sort of secondary stream.

So like, yeah, if you, if you are interested in these inbox and outbox of this user,

you might also care about these other streams.

And when I think about, um, you know, the way we use, uh, activity pub right now,

it's basically like, okay, I'm gonna subscribe to you on mastodon and on funk whale and pixel fed,

right?

Like, oh, but it should just be like my feed should consist of a whole bunch

of these sub feeds that can, you know, go to the right place.

So the, for the folks who are actually implementing, you know, these protocols,

like what are your thoughts on that?

Matt Baer

Uh, I don't have any solution for that, but I, I think it's, uh, ZOT, ZOT, ZOT?

Yeah, there is a protocol to, to do federated, uh, identities and nomadic identities.

Speaker 1

So maybe it's in the protocol now, like it's in, it's in activity pub where you can just set secondary streams.

Matt Baer

Oh, oh, I didn't know about that. Sorry.

Speaker 2

Uh, honestly, I didn't know about that either.

Chris Webber

Everybody's just looking at mastodon's code base.

Corey Slepp

So someone who co-generated the spec front and treated the spec as data, I am aware of that and everyone's lack of supporting that.

Um, but since I'm a library, I don't really have power to go tell people how to build applications and how to use the library.

Speaker 1

So, um, we can use your input.

Yes.

Chris Webber

The users should stand up and demand power from the implementers and specification office.

Speaker 1

Yeah. So I, I have no question.

I have no, it's all.

So, uh, thanks for mentioning, uh, test suite, the federated test suite, but it's, it's not, the test suite is not called FENAS.

Um, FENAS is the Federated Networks Association and one of our main goals is to actually, yeah, get everyone together.

So that is what you actually mentioned with the forum and correct me guys if I'm wrong, but, uh, we actually exchanged already some mails with the forum you mentioned.

So if someone is interested in the association, then yeah, we should definitely have a talk.

Okay.

Very good.

Is that it then?

One last?

One more.

Aha!

Okay.

Uh, you already talked.

So I have a troll question.

Uh, because, um, a few months ago I bumped into, um, some articles and, uh, also conference, big conference with big sponsors, which says blockchain 3.0 and the future of decentralized internet.

What about it?

Uh, I had a really, they are in the spotlight, you know, uh, everyone everywhere you hear about decentralized internet.

It's always blockchain here, blockchain there.

Chris Webber

So my favorite blockchain is get with signed commits.

Uh, uh, but the, I mean, blockchain very vague, what that means.

Cause there's a whole lot of things that it could be.

It's the cloud of, uh, Merkle tree situation.

Uh, the, but you know, I had an interesting experience.

Uh, there's a lot of hype around blockchains right now.

Cause there's a lot of money around blockchains right now.

Uh, I had an interesting experience at rebooting Web of Trust last year where I was talking with somebody who said, I'm really excited about blockchains cause they can finally bring decentralization to the world.

And I'm like, they have their uses in particular domains, but sometimes you don't want the overhead of a database that grows forever.

And, uh, you know, all of the, you know, like depending on which definition of blockchain it is, there are some other computational things overhead.

You know, I, I'm interested in the actor model, you know, in my own work and stuff like that.

And they said, Oh, I thought that blockchain just meant decentralized systems.

And I was like, now I get it right.

Like, so I think that like, um, that's a, the only exposure that many people have to these things.

And I think there's a lot of cool things that the person who was standing next to me, Mark Miller, who works on has, you know, done a tremendous amount of work and object capability said something really brilliant.

Uh, at that moment and said, there's only one case where you need a blockchain and it's a distributed system where the ordering events is critical to its operation.

That's the only case.

Um, double spending problem makes sense if you need a decentralized payment system.

There are lots of other cases that don't need that.

Um, but I do think that there are cool things you can do with things like secure scuttlebutt and stuff like that, that are blockchain-ish, but a little bit closer to a Git repository.

Um, where you have no guarantees that won't fork than, you know, like this thing that requires consensus.

Yeah.

Uh, I think it's, do we still have time for, uh, um, the GNU social final question?

Speaker 1

Uh, sorry, I'm just hijacking, but there are already, uh, social networks running on blockchain and it's really awful because you have to download the whole chain and it takes five or six hours before you have to, you can, you can use it.

Maybe you have a lot of hard drive space.

I don't.

Yeah.

The, what I'm thinking is like the, what I would like to have a discussion about is like how many social problems we're trying to solve with technology, for example, discoverability, et cetera, et cetera.

Considering how we have the federated space and we sort of tend to think about it as a distributed database.

However, it's not distributed, it's decentralized.

So like you have different aspects.

Every server has a different view of the network and that's like what's causing all the problems with discoverability, et cetera.

Uh, so I think whenever you start thinking about these, uh, these issues, then remember like what is the network made of?

It's made of people.

How do we create a social web?

We'll always create it with the people using it rather than the technical issues.

Technology is meant to like make it easier to use of course.

And by the way, there's like this open search standard for searching and like discovering search endpoints for various objects, et cetera, for servers on, on the web.

You heard it.

Chris Webber

Uh, the fed versus people it's people.

Anyway, uh, I think that was the last question.

Is that correct?

Yes.

All right.

Thank you everybody.

Uh, happy to talk in the hallway if you want to.

Thank you for the fellow panelists.

Speaker 1

And everybody who has implemented a youth activity pub.

Yeah!