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

And we'll just pass them the mic and see what happens. I guess the mic is being passed to the middle. Hello everybody, how are you doing? We're getting... Yeah! Preaching the end of the first day of Fosdom, so everybody's probably a little bit exhausted. I'm Chris Weber, I'm one of the co-editors and co-authors of Activity Pub.

Just out of curiosity, how many people here are familiar with Activity Pub, raise your hand. Okay. You know, a good portion of the audience, not everyone. Also, how many people have looked at the Activity Pub specification? Wow! That's like a lot of people for a specification. So, for those of you who aren't familiar, 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 the social sites. Anybody should be able to run their own server and speak to each other,

and Activity Pub 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 Weber. I'm going to pass it this way, and then it will wrap around like Mario 2. Hi everyone, I'm Elliot, I'm the maintainer of a software called Funk Whale, which is basically a GrooveShark slash SoundCloud alternative,

working with Activity Pub and other decentralized technologies. Hi everyone, I'm Matt Baer, I'm working on a project called WriteFreely, that's basically a really simple blogging platform that also integrates with Activia.

Hello, I am Corey Slep, I work on GoFed, which is a GoLang implementation of Activity Pub, a library, not an end user app. I'm busy working getting V1 out, so I'm here on my individual capacity, and I don't speak for my employer.

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 Activity Pub specifically?

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 Activity Pub in FunkWale is used not at all for user interaction,

but more for server-to-server interaction, because FunkWale uses Activity Pub to exchange music from servers to servers, and Activity Pub helped me do that, and I don't know if I could have done that with something else

without reinventing too many things. For me, I was just really attracted to how easy it was to start up communities that had their own flavors to them and could still communicate. I started running a Mastodon instance,

and that really got me to seeing the type of people that were coming on board and seeing how everyone interacted and how the software worked, how you could have music or video or just small posts, and they all come into one place. So I thought that would be perfect to build on. I would like to add to it.

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. I've had a couple of users. I think WriteFreely is one of them.

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. Before I throw on the next question,

I just wanted to say 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 a 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 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 slash hate? Anybody want to go first? Don't be afraid. I won't get mad. I like ActivityPub because...

I like it for what it does, 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.

I agree. Can you hear me? One thing I really liked is that it's made of small pieces, so you can pick webfinger or activity streams,

and it's conceptually easy to get. For Frank Whale, 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. 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. 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 understood. The hardest part was the implementation, just going from the spec, started reading through it, did not finish it. 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, doing the dirty work, so that's pretty much why I could end up implementing it. Great. 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. That would be really great.

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, but we did leave some gaps in the spec,

and that's correct. 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 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 inbox, 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 Sprightly 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 Golem. So that's going to be my next couple years as trying to develop demos that piece by piece show how we can bring the thetaverse 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 any of you have a question that you'd like to move forward on? Alright, I bet some people have questions. We have at least one. 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 to see how they did make it. But our project is fairly complicated, so we have a much larger thing to implement. Then I came to a point where I was unsure how to implement this or that.

So I guess it would be important to have some kind of coordination, some kind of discussion forum. 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 who would be standard conform, not only for our software, but something that all would implement

that way or another way 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 out to set out standards, this is a space to incubate ideas and figure out the next generation,

the 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.rocks 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? What? Socialhub.network. Right, socialhub.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? No, about socialhub.network. Yeah, it's really interesting. I'm using it for FunQuail. And if more projects came and used it all together, it would be interesting to coordinate on developments and fill the gaps in the specs or things like that.

Sorry, I have one last thing to say. 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 activity pub extension and embed it into activity pub itself. So your extension to activity pub can federate, which would enable decentralized authorities managing their own activity pub 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 Fediverse. However, you don't have the problem of a centralized authority where it's David versus Goliath kind of situations and acrimony and power struggles. Each person can manage their own, or group can manage their own activity pub extensions.

So it's an idea I really want to explore. We should talk more after this panel. Other questions? I'm impressed by the number of people who said that activity pub is simple because I feel really stupid because implementing it was harder for me.

What's your project name? What's your project name? Excuse me? What's your project name? I just had a question. It's not released yet. Oh, okay, okay. Cool. Maybe it will stay internal. The biggest difficulty for me was to understand that activity pub by itself is not important. It's actually Mastodon Pub being compatible with Mastodon,

which is a real goal for most people. And then there are a lot of things you don't find. I've read the specification, and it's only a small part of what you need to know. You need authentication, authorization, web finger, encoding of content. A lot of things are completely not specified. So to be more concrete,

do you think it would be a good idea if someone were brave enough to describe the actual profile which makes Mastodon Pub, or whatever its name, all the things that you need to know when you want to be a part of the 3D verse? I think that documenting how to be compatible

with the, let's say, average current deployment of Activity Pub would be good. And especially a lot of people want to be compatible with Mastodon especially. And in fact, I think that Mastodon compatibility is something that is important and useful for many people in this community. I also think that for those people

who are trying to do things that are not just Mastodon, that are not just microblogging things, we also want to be able to have conversations about how to do that as well. How do you post it in audio that Funkwell will be able to receive and stuff like that. So I think we'd like more of those sources to be able to do those things.

And my main work that's coming up is going to be talking about much more next-generational things, but we should document at least the current generation things that are not specified. Yeah. I believe there is also a project called Phineas maybe. It's a test suite, automated test suite

that can assess compatibility between different federal software. So you could test and build automatically each Funkwell release and test it against Ride3D or Mastodon or Pleroma. Oh, okay. So congrats. Thank you.

Yeah, I was just going to say, yeah, I think also as people implementing it, you know, I've been meaning to do this, to just write about it in general, just talking about, okay, this is how I did it, this is how I did this one piece of functionality. I think just everyone, especially while we're all kind of exploring

and trying things out, that's what we should be doing as well as part of the development process. Other questions? Yep. Ready. Nope. Right there. 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 your own idea 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.

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. I read the notes. But I really view ActivityPub 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 bite transmission protocol, getting bites 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 activity streams and vocabularies into other domains like the economic and the CodeForge domains.

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. Did that answer your question? 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 activity streams and in 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? 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 activity streams 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 the one other thing real 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? Yeah, I would just say as far as today, especially there are a lot of different applications. Right Freely is one of the more lightweight implementers

of ActivityPub, and that was just a design decision. So that's kind of how, there's definitely the protocol side that can do a lot, and it does have a bit of that application layer, but it's really, if you need it, then, 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? Any more questions? Oh, sorry. Yeah, if an answer to my question is out of scope for here, please say so.

I have no personal experience with social media. I've seen websites, but never used it, and I dislike centralized stations. 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, and can you give an end-user benefit of the federation between different platforms? Okay. What would you say? I've got too many opinions on this. I'm going to hand this off to one of you. What is the end-user benefit of federation?

For Feng Kui, our use case is to have people sharing music and creators sharing their music publicly, and to have people commenting on music and 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. Do any of you else? I'll let you. Oh, I really wanted to talk about the thing that I just remembered in part for the other question.

It's allowed really cool interactions where you can have a microblogging site like Pluroma or Mastodon, have its users sharing their thoughts, and then as well, with PeerTube, for example, someone uploading videos, whether it's video blogging

or whether it's instructional videos, and that will pop up in a Mastodon feed, Pluroma 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, and your Mastodon feed 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. If I want to use it, it's precondition that I have an account on each of those services.

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 pubs 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

and PeerTube's interface to talk to Funk Whale or anything like that. But the way that the Fediverse is currently designed is actually really bizarre to me, has been to encourage each one of the projects that has come out has wanted to brand themselves

as the activity pub server for this. And it's cool that these different things are happening, and maybe that actually motivates developers, and I'm sure you all have comments on this, to be able to do that type of thing. But to me, so my friend Sebastian and I were just talking about this,

and there are a bunch of people who are currently leaving Google+, who are really disappointed, because one of the things that Google plus 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. I don't see why we shouldn't try to pursue this vision of 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 it's an answer to your question is that you wouldn't need five different accounts. Yeah, indeed. 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 borrow 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. This is actually somewhere I've been thinking as well, and maybe it's what you're saying. I think we're 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,

through the client to server, send it to Mastodon or something. So that's kind of where I've been going. In addition to the WriteFreely side, the actual producing content, I'm working on the reading side, called Read As, and that's basically just 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 WriteFreely to where you have 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 your blog or wherever else in the Fediverse that you're kind of connected to. So I've kind of been thinking about those lines.

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, peer-to-peer solution, because, for example, the assumption that 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. I would like to know if my impression is wrong or if it's like that. No, you're right, but there's no reason that it actually has to be the case in my view. I actually think that there is no, so you're right. I actually think that one of the weird things that happened,

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 ActivityPub, but maybe we should actually talk. 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, and you're like, hooray, I've decentralized things, right, 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 in peer-to-peer systems. 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.

Two, ISPs, IPv4 started to run out of spaces, and we started to get more NATs, and ISPs actually started to put in their terms of service that you can't self-host a server, right? Three, 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 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 the server-to-server protocol, there's no reason if I spin up a Tor onion service for ActivityPub and host it on my machine that's right there, aside from the liveness problem, there's no reason that I can't actually send a message to another person who's hosting an ActivityPub service over a Tor onion service that's just running on their own local machine.

And another reason for that I think has to do with a complicated topic called Zico's Triangle 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. Do either of you want to discuss it or should we do?

Next question. Next question. Yes, one thing I like about ActivityPub is that it does everything that O-Status did. I'm from Genome Social. And the thing I dislike sort of about ActivityPub is that it tries to sort of portray an image

of serving private content in some way or like ACLs and stuff. Like there's the notion of a private message or a direct message or whatever it's called. I think somewhere it's explicitly that the spec doesn't have the scope of preserving privacy

or guaranteeing the end-to-end encryption or whatever. It's explicit in the specification I remember. I'm thinking, considering the last talk, that we should be open about how political code is

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

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

Shared inbox moves from the idea that you're sending a message directly to another entity, directly to that entity's inbox, and instead assumes that you start routing things based off of the server that you're sending to, understanding of the addresses that are coming in. That's a big problem. ActivityPub, as it's designed,

we'll state, 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, it's semi-true, it's as secure as email, right? As much as I can send an, and in fact, Evan Prodromo designed it specifically influenced by email

in that it has email-like addressing where you do two 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 end-to-end encryption, the reason why we might want that is that a server, 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. You'll notice how well email is doing with the end-to-end encryption thing, which is pretty bad, you know?

And I'll finish this, and then I'll get back to you. And there are things like oMemo and things like that that we could observe. We actually had an issue in activity stream, 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,

comment about more peer-to-peer delivery, where we're doing deluxe messages between two different people's home computers, this entirely disappears. If the server-to-server transmission is from my Tor onion service on 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.

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 raised your hand again, so what was the follow-up?

Can you repeat the question? The question slash statement was,

in a federated server environment, you always have the problem of the server basically sending things around from place to place. If you take the activity pub 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 public inbox or followers, things get more complicated. The original version of activity pub, you would still post, except for the public inbox that we had and then removed, you would still post directly to each follower's individual inbox. The shared inbox that we then discussed later

would actually, 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, 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. That didn't happen partly because the response from Mastodon, which I said, okay, that makes sense and I moved forward with at the time,

and then later regretted, 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 activity pub being very secure from an object capability perspective. There are no ACLs in activity pub, by the way, and there shouldn't be,

but people have discussed it, possibly adding them. This is one of the things I'm going to be exploring with brightly is how to make activity pub into a very secure protocol developed from object capability security literature. So anyway, that's my response. It was kind of long. I'm sorry. If you're more interested in following along

someone who's pursuing this, Lightpub and a Pluroma developer named Kanini is looking heavily into this area. Next question? Yes, so more back to philosophy and economics. Popular microblogging platforms,

I heard, are Twitter and Instagram. Will they adjust for compliance? Oh, will they pick up activity pub? Or otherwise, what reactions come from that category of providers of microblogging?

Will Twitter or Facebook pick it up, or will they even notice? I'm sure they've noticed a little, but they clearly don't care too much, partly because we haven't really hit their radar on the level of success, I think. I mean, we've got a couple million users now, but it's not really enough to really worry Facebook or Twitter. I think you brought up regulation, like whether or not a regulated organization

might force them to federate or something like that. I think that would be really interesting and I think very unlikely to happen. But anyway, I think they're kind of ignoring us, partly because I wrote in a blog post, one of the reasons that the big players, I think, haven't actually had to really fight us in any way

is that we tend to spend a lot of time fighting with each other, and we do that work for them. So I'd like to do less of that, more collaborating. But anyway, I have very little hopes that organizations whose profit model is entirely based around them being the walled garden of your content are going to be interested in picking up the Fediverse, basically.

Hi. So 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

to do things like sometimes I'm going to be a list, sometimes I'm going to be a string, sometimes I'm going to be this, sometimes I'm going to be that. And specifically I was looking at GoFed, and that, I mean, you had to generate so much code 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, right, another comment. I really like WebFinger, and I wish that in the social aspect of it it was more clearly specified that WebFinger is a nice thing to look up email-like identifiers.

Actual question. Have you looked into federating, sorry, cooperating with XMPP, Standards Foundation, specifically to replace the microblogging specification or something like that? Did you get in touch with them?

Because that thing is based around Atom, but not even like, or status used it slightly differently, slightly incompatible, and probably not really trivially interoperable. So is there any work interacting with them? XMPP is awesome, and it was my first federated love.

So first I want to say that. And more people should run XMPP. I hate the fact that XMPP is kind of dying. My buddy list is very small. And I blame partly large corporations picking up XMPP and dropping it, in fact, which could happen to the Fediverse if Facebook or Google or whatever did pick it up.

Did we talk to them? I have talked with them a number of times. What time is it left? How much? 15 minutes left? Oh, that's not bad. ActivityPub, I actually asked Evan Prodromo 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 user individually or if the server is doing things. And now there's maybe this standard, which didn't exist with the time we started. But I think that part of the other reason for it

is that ActivityPub 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? You're going, eh, but I've never seen, yeah?

It's a specific personal, it can be mapped if they looped anything remotely similar. It can be mapped if you kind of squint your eyes

and you figure out how to, and you intentionally make that a decision, right? But it's not fundamentally a web protocol, right? It's not fundamentally the way that ActivityPub is. 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 ActivityPub, and it's not done intentionally for a reason. And let me be very clear about why that is.

In fact, 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 ActivityPub, which is to use the ACCT colon URI 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 ActivityPub spec, and that's not how it ended up shaking out,

basically because of the way that implementers were already using WebFinger. However, the reason why we're not using WebFinger specifically was 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 to do securely transmitting things over 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. And there's an if we require WebFinger.

And actually, that's one of the biggest reasons I'm going to argue, and that we'll get into more with the Spritely papers, about why federated social web things are so hard to roll out is partly our reliance on DNS and SSL security authorities. If you imagine, instead,

Bob at 200charactersofgarbage.onion, nobody could address that guy, right? There is a solution, it's called petnames, and we'll get into it more throughout the Spritely project. 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 him, so. Okay. Let's let him respond, and then I just won't respond. Just for the GoFed part, V1, you can compile on Raspberry Pi 3, so.

Okay, next question. Hey, so we're from Dublin City University, and we're working on a social blogging platform using ActivityPub. And we are worried that a federated social system is more susceptible to the problem of echo chambers, 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. We've got at least one person over there

who is Arne, who you should talk to, who works on this stuff with FreeNet. I'm going to hold back from commenting. Anybody else? I just want to say, as implemented currently, Mastodon and Pluroma tend to be very account-centric with discoverability, and there's no reason

it needs to be account-centric discoverability. I was discussing before with some other folks interested that it could be a server-to-server discoverability this discoverability problem has not been solved at all. 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. There is funding for discoverability if you didn't get the word yet. And then net.nl slash discovery, there is 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, if you do a recommendation, be very, very, very careful about spam. I'm release manager of the FreeNet project, and we have some spam defense in there

which does not rely on any centralized service, but it's a problem which can really easily go bad and which is not trivial to solve. I have some math lying around that shows that we can actually scale it up to the million or billion scale if we accept that there is no global visibility,

that visibility goes only over connections between people, and it should be possible to map it to non-FreeNet stuff. In FreeNet stuff, basically, it's that there's a shared database which you can access where you can have anonymous accounts, and this has to be somehow mapped on the federation.

But then maybe I can give Christopher the address of some reference for that so he can pace it around in the right discussion forum. Let's chat more. Let's distribute these ideas, yeah.

Hi. I just wanted to make a bit of a reaction to your quick dismissal about the possibility of cooperation implementing ActivityPub because no one thought Microsoft would buy GitHub that long.

So I think dismissing it is not a good idea. It's really about addressing it, and 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. I agree, 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. I think having decentralized authorities can really help with distributing the power. Again, thank you for your excellent talk.

So I have a question for everyone but Chris. So the implementers. So there's a part of ActivityPub that talks about streams, and it basically looks like no one really uses that sort of secondary stream.

So like, yeah, 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 the way we use ActivityPub right now, it's basically like, okay, I'm going to subscribe to you on Mastodon, and on FunkWale, and PixelFed, right,

where I'm like, oh, but it should just be like my feed should consist of a whole bunch of these sub-feeds that can go to the right place. So for the folks who are actually implementing these protocols, what are your thoughts on that? I don't have any solution for that,

but I think it's a ZOT, ZOT, yeah, there is a protocol to do federated identities and nomadic identities. I mean, it's in the protocol now. It's in ActivityPub where you can just set secondary streams. Oh, I didn't know about that. Sorry.

Honestly, I didn't know about that either. Everybody's just looking at Mastodon's code base. So as someone who code-generated the spec and treated the spec as data, I am aware of that, and everyone's lack of supporting that. 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. We could use your input then. The users should stand up and demand power from the implementers. And specification office. Yes, so I have no question.

Thanks for mentioning TestSuite, the federated TestSuite, but the TestSuite is not called FINIS. FINIS is the Federated Networks Association, and one of our main goals is to actually get everyone together. So that is what you actually mentioned with the forum.

And correct me, guys, if I'm wrong, but 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. Very good. Is that it then? One last? One more. Aha!

You already talked. I have a troll question. Because a few months ago, I bumped into some articles and also a conference, a big conference with big sponsors, which says blockchain 3.0 and the future of decentralized Internet.

What about it? I had a really... They are in the spotlight, you know. Everyone, everywhere you hear about decentralized Internet, it's always blockchain here, blockchain there.

My favorite blockchain is Git with signed commits. But, I mean, blockchain is very vague what that means because there's a whole lot of things that it could be. It's the cloud of Merkle Tree situation. But, you know, I had an interesting experience. There's a lot of hype around blockchains right now

because there's a lot of money around blockchains right now. 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 because 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.

Depending on which definition of blockchain it is, there are some other computational things overhead. I'm interested in the actor model, 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?

So I think that that's the only exposure that many people have to these things. And I think there's a lot of cool things that the person who is standing next to me, Mark Miller, who has done a tremendous amount of work in object capability, said something really brilliant at that moment and said, there's only one case where you need a blockchain

and it's a distributed system where the ordering of events is critical to its operation. That's the only case. Double spending problem makes sense if you need a decentralized payment system. There are lots of other cases that don't need that. 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

where you have no guarantees it won't fork than this thing that requires consensus. Do we still have time for the GNU social final question? Sorry, I'm just hijacking, but there are already 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 can use it. Maybe you have a lot of hard drive space. What I'm thinking is, what I would like to have a discussion about

is how many social problems we're trying to solve with technology, for example discoverability, etc. considering how we have the federated space and we tend to think about it as a distributed database. However, it's not distributed. It's decentralized.

So you have different aspects. Every server has a different view of the network and that's what's causing all the problems with discoverability, etc. I think whenever you start thinking about these issues then remember what is the network made of? It's made of people.

How do we create a social web? We always create it with the people using it rather than the technical issues. Technology is meant to make it easier to use, of course. And by the way, there's this open search standard for searching and discovering search endpoints for various objects, etc. for servers on the web.

You heard it. The feta versus people. It's people! Anyway, I think that was the last question. Is that correct? All right. Thank you everybody. Happy to talk in the hallway if you want to. Thank you for the fellow panelists and everybody who's implemented and used activity pub.

Yeah!