At 17:08 you start talking about how data is pulled from a PDS into an application indexer/craeler “in ActivityPub”…. I think you meant to say in “AT”…. But otherwise, thank you for the clear explanations.
I was very excited when I heard of ActivityPub with the recent Reddit mess, but as I research more, I cannot stop feeling just confused. It just feels incomplete to me, the integrated Object support for example is extremely basic, and while it is very easy to modify and extend but the more you do it the more it stops being compatible with other instances implementations. You cannot browse Lemmy through Mastodon for example, or even if they are very similar, Kbin and Lemmy have compatibility issues. It really does feel more like a framework for a protocol rather than an actual usable piece of software that could power the "future of social media". What pains me the most is that even though this "instability" is obviously an issue, I feel like all of this could have been avoided with some better communication and stronger conventions, even some stricter rules, but now with so many different implementations and some of them becoming more and more alienated from one another it feels like we are just in too deep and the entire point of the protocol seems lost to me. I really hope ActivityPub works in some way, at least set an alternative to regular social media, but I simply cannot see it as a replacement.
Compatibility between networks comes down to data structures, not how the data is sent between servers. Twitter, Google+, and facebook all let you export and “own” your data but there’s no way make that data compatible and import it between networks.
Actually, Mastodon has partial support for Lemmy threads: you can read them, they just don't always work properly. That's planned to be fixed in an upcoming update.
i dont think it'll replace regular social media, and it doesn't really have to. activitypub will likely run parallel, each catering to different users.
@@JustinGarrisonwell the protocol shares the data structure in some way. The internal data structures of implementations can be different, but if they can be communicated through a common protocol the implementations can be compatible, no? In the end it's a question of how easy it is to map the application user-facing behavior to the protocol, and how much the application designers care about interoperability in their ecosystem. Threads certainly won't care very much about interoperability with mastodon i think. Will bluesky maintain a close match between application layer features and protocol layer, and ensure high interop with other implementations that they do not develop? We'll see.
Great high-level overview. What is super exciting is that this architecture plays well with other protocols. How the PDS is stored and indexed is an implementation detail. I can see eventually people storing their PDS on multiple nostr relays for example.
I didn't understand much of what you described even as I've spent alot of time in tech but have moved more into management but i appreciate you guys covering these new protocols and technologies, so we aren't completely aloof when these terms pop up in meetings. I wonder how you guys learn these things so fast
I don’t know about other people but for me I usually learn by using the tech. I wouldn’t say this was “fast” because I started learning activity pub a couple years ago and took over a month to make something that worked
So you mentioned that within the PDS you cannot remove data and its essential logged in its history forever. If I own the data in my PDS, can BlueSky for example see what I liked or disliked, if I own the data, can they view the entire history of it, can they access that and use it? If so, how do I own my data, if its public...? Hope the question makes sense! --- Also thank you for posting the video, I started learning about Federated Protocols today as a fun little Saturday Activity and this is really helpful in understanding the underlying structure of how ActivityPub and AT Protocol work. Super engaging and fun to watch :)
Glad you found the video and thank you for the comment. Right now everything in AT protocol PDSs is public. Some things are unlinked/ignored at the application crawler layer. It’s the reason why Bluesky doesn’t have DMs. Mastodon doesn’t (yet) have private DMs either because admins can see all messages. Both protocols are working on creating private messages and deletable content but it’s still a work in progress.
@@JustinGarrison Actually Mastodon has DMs. Yes, admins can see all messages. If you DM someone at Instagram, twitter or facebook, admins can as well see all the messages. Having E2E encryped messages is not a requirement for DMs. Even in Telegram (if you don't activate E2E encryption specifically for your chat) all the messages can be read by the admins. So with ActivityPub you can say "just show it this people" and then just these people + the admins of the instances of these people can see it. But still better than completely public.
There are many things in this video, that are wrong. - ActivityPub doesn't work like RSS. In the opposite, it works more like E-Mail. When I post something, and you follow me, I send my post to your inbox. And from there your application can present it to you. If you like it, you send that like to my inbox. Instead we could have send E-Mails. RSS on the other side doesn't send anything. If I post something in an RSS feed, you have to ask my server for updates. Actually that's how you described how the At Protocol works. There you have a server with your data and others have to crawl it from there, right? So if you want to stay up to date, you call it maybe once very 5 seconds? While with ActivityPub you push it once to the follower's inbox and that's it. Also as ActivityPub does it, the post is now on both servers. - You are right, that a lot of servers talk to each other. But you are wrong with the scaling. There is no issue with scaling. It works similar to email, and emails scales very well over different servers. If you run a server, you don't have to configure all other servers. It's just, that your users connect with other users and they exchange messages. So your server is just sending data to other servers, if your users do something, like post, follow, like, etc. Other servers only send your server data, if someone on the other server did something, that effects your user. Else no data needs to be exchanged. So the size of the server depends on the number of users you have and how active they are. - You explain instance blocking as something negative. It's actually a big feature of ActivityPub. The most important thing of a social network to work well, is good moderation. Without that you are flooded with advertisement, hate, porn and other stuff, you might not want to have. - It's not true that with ActivityPub you can not move posts. You can implement that. It's not a problem and Mastodon has that feature in their Backlog. The problem with it is moderation. Maybe a user is coming from another server to my server and I have rules on my server about the content. But when I allow them to copy all their post onto my server, I will probably also copy posts I'm not allowing. So I would have to moderate thousands of posts. Also someone could do that maliciously and import posts to reduce the reputation of my instance, saying "look at all the posts here, that are hateful, this is a bad instance", but they have just been imported. So maybe as an instance you want to mark them as imported. They haven't solved such questions, so they didn't implemented it yet, but it will come eventually. - Sure, an attacker could take over an instance and manipulate stuff. The same thing can happen with the AT-Protocol. I don't see a difference there between the protocols. Somewhere the data is stored and that can be manipulated, if a hacker comes into that system, whether it's a PDS or ActivityPub Server. - You are wrong with where images are stored. I don't know the AT Protocol so much, but for ActivityPub it's not necessarily the case that they are stored somewhere else. With Mastodon they are stored on your instance, together with your posts and Mastodon also stores images and stuff from other instances as well. So if you follow someone, all their images are stored on my Mastodon server as well. I think probably for privacy reasons, because I the other instance would know, when I load the images. Maybe to keep a good performance, I don't know. It seems to be a waste of resources for me. So for ActivityPub it depends on the implementation, but can be within the server itself. - 14:09 Well for ActivityPub you can do the same. So PeerTube does video and Mastodon makes microblogging and Pixelfed pictures. But you can implement an ActivityPub server that can post videos and microblogging and pictures. It's just different content you publish over the same protocol. And they can speak with each other. There is no problem to implement an ActivityPub server, that is completely agnostic to the fields and implement clients separately that have different views or different use cases. Also the existing servers already work together. You can follow someone on Pixelfed from your Mastodon account and see their data. So having the separation of storage and functionality already in the protocol is kind of a smart move of the AT protocol, but similar architectures can be build on top of ActivityPub, without any problems. - You say that the crawlers in the AT Protocol would scale better than ActivityPub. How is that the case? As you explained, when I push something, it's added to my PDS. So the crawler has to ask my PDS "hey dude, is there new content?". How often does the crawler do that? Once an hour? Then it needs an hour until my post is visible for other users. So let's assume there is a big event, like a football game. And I post something about it, I want others to see it right away, right? So with ActivityPub my server pushes it to my followers and they can see it in less than a second later. With the AT protocol, the crawler has to ask the PDS of all the users all the time, right? So it has to ask my PDS "hey dude, is there new content?" maybe every second? 86400 times a day? And for a million users, this crawler has to do 86400000000 requests every day? Or do they accept a delay and just load the data every minute? Or is it just active, if I load data on my client? So let's assume I follow 500 people. So then I open my client, and that client asks the crawler for data, the crawler then asks the 500 PDS of the people I follow, if there is something new and then presents it to me? Doing 500 requests needs a lot of time, so I have to wait a while, until data pops up in my client? Both variants don't scale. So either it works differently from what you presented or it just works because bluesky has direct access to all the data and can optimize it. But it doesn't sound scalable, while ActivityPub totally scales. Everything that happens in ActivityPub follows an user interaction. So there is no polling and things like that, that could be a problem for scaling.
Instance blocking is not part of the ActivityPub spec, not sure where you got that. How is he wrong about scaling? When ActivityPub instances make duplicates that’s not efficient
@@Cloudymindxii blocking is in the hands of each implementation. It doesn't have to be part of the specification. About the copies, if you don't have a local copy, you have to ask all servers every time a user updates their stream. Calling 100 servers each time I request updates doesn't scale, too. So what's the alternative? They don't have to duplicate content forever. Just for the recent posts it makes sense to keep a copy until it's download to the client. It's like email, instant messengers, etc. You keep a message of the messages at least until they are downloaded.
Posts and stuff not transfering over is a very relative concept, most AP implementations allow you to export / import your data, so if you had 10k posts on server 1, you can migrate your account, export your data, and import it in the new server, sometimes the timestamps will be wrong, but at least the posts are there... As for media not being in the server itself, in AP, most of the time, it is. Most instances actually do host their media in the same server, because most instances are people owned, and we generally hate big tech companies such as Amazon, so we are never going to store our data on their servers, the whole point of decentralisation is to keep data in OUR servers, not the cloud (someone else's computer)
@@JustinGarrison Honestly I don't know, I don't think so, but then again, I don't use Mastodon, so I can't really tell you how long it has been in it or even if it is a festure, but it 100% is an option in Misskey at least...
Also Mastodon plans to integrate a migration of the full post history to the new server. But there are some tricky questions. Malicious users could use that to import posts that violate the rules of the server. Also there could be a couple of GB of posts. So importing so many things at once may cause problems to the instance administrators. So there need to be ways to regulate it. Mastodon hasn't found a good solution for that so far. But anyone can implement that to their software, like Misskey does.
@@Duconi There is a solution to that, private, or controlled sign up instances... Most instances won't allow anyone who stumbles upon them to sign up. That's a way to avoid malicious users signing up. Decentralized moderation is the most effective kind of moderation.
Maybe. I think they have thought about it a lot and maybe it doesn't fit to the way they want their software to be used. What do you mean by decentralised moderation?
ActivityPub may be more stable but AT protocol is clearly more advanced and clearly what would solve the huge problem we are having at the moment with walled gardens that became obvious with the Twitter disaster
The most important feature will be interoperability. For example, having the same data (friends, posts, chats) on META and Agora Social. If I post on Agora Social, the same post can be read/interacted on META and Agora Social.
Activitypub is supposed to allow interop. Thread users should be able to see and interact with users from federated mastodon/lemmy/... Instances, in principle. One variable is how instances federate, and another is how application-level features translate to the protocol level in a way that other federated instances support.
I truly REALLY appreciate your time and effort in presenting these topics and comparing and contrasting these two protocols in particular. But I'm confused and frustrated on a whole 'nother level about them (NOT YOU, them): So they're going to DECENTRALIZE (yea!) social networks by ...CENTRALIZING them on yet another server?!?! Does anyone actually build real APPLICATIONS anymore? Or is EVERYTHING always MY DATA on somebody else's SERVER?! Are we truly unable to create networks that simply facilitate the connection of my computer to my family and friends' computers? Yanno, a actual SOCIAL NETWORK?! i REALLY think we're still totally misusing the internet and WWW tech stack, and I think we're stuck thinking that way because we've been brainwashed by Big Tech firms that that's the way it has to work. From their perspective, they're right, it's the only way THEY can profit from ME communicating and sharing with MY FAMILY AND FRIENDS, and from 'allowing' me to discover new distant/near virtual friends who are content creators whose content and POV I want to experience. Can we TRULY not DO BETTER?! I'm about ready to go back to dial-up BBS if necessary. I KNOW I can secure that and use it. Did fine with it throughout the late 1970's and 1980's and through a fair bit of the 1990's. Yeah, it's gotten that bad today.
Yes, Diaspora for example has their own protocol, that is also supported by Hubzilla and Friendica. There is the DFRN protocol which is only implemented by Friendica, I think and there is the zot protocol spoken by Zap and Hubzilla. But except Diaspora, I think they all also speak ActivityPub now, and there is a lot of new software that only speaks ActivityPub, so I think if a social network isn't speaking ActivityPub, they will have a very hard time to establish themselves.
implementing AP myself, and a big roadblock for me is authentication. I initially thought AP would provide a way to authenticate against another server, but this is false. From my understanding, AP is only for defining common social activities. All the authentication, algorithms, and storage are up to you to build. So, IMO AP is not a solution to anything. It just makes it slightly easier to share data with other servers. Someone, please correct me where I'm wrong. Where things get muddy for me, is the spec is abstract enough that the federation could totally start including auth as part of the spec. All they would need to do is include 'instructions' in the profile resolved by webfinger.
A new model of content creation /storing has to be considered - not technically, but socially/culturally - creating evergreen content and creating 'time-constrained' content and being able to technically flag which is which, so servers know what to auto-delete after 30 days, or whatever the server chooses. There's no way decentralization can scale by allowing the internet to remember everything, already we're seeing TH-cam publicly straining with their move to disallow ad blockers, Twitter obviously, and fediverse admins. Deletion needs to be taken seriously. Otherwise it'll have to move to charging users by their data size+calls to access the data, which will never allow true public adoption of decentralized protocols. The more I think about it, the more it makes sense for admins to auto-delete posts/content older than 30 or 180 days.
So, ActivityPub is expensive because the volume of data transferred from server to server when servers have thousands of users. I would think an implementation that is intended for a single user instance would mean that the costs could be distributed equitably. 1 server with 1000 users costs $100.00 per month, 1000 instances with 1 user, each user pays some fraction of this to, host/own/secure their own data. Implementing something like this using a serverless infrastructure could keep costs very low per user. Users with a ton of followers and posts would get more traffic.
Check out wildebeest from cloudflare. It’s a serverless implementation based on their services. It costs a minimum of $10/mo because you have to pay for a higher usage tier of their services
That's kind of true, but not fully. Small ActivityPub instances cost way less than big ones, but it's not 1 user 1$, 1000 users 1000$. One reason is, that servers usually cost money independent of the usage (except you implement it in AWS lambda or something similar, where you pay per request, so you are right). So a small server costs maybe 5$/month. So if their resources are enough to handle 10 users but only one uses that server it still costs 5$/month. But you are right, with serverless infrastructure, that isn't such a big factor. The other factor is data. If you have 10 users and each follows 100 people, maybe some of them follow the same person. And if that person publishes something, your server has to store it once instead of multiple times. So with more users there are more users that follow the same persons, while when each user had their own server, the data had to be stored more often. This is especially important for Mastodon, who decided to not just store the post locally, but also the media files. So even if you use serverless infrastructure, if you have it for 1 user, you have to store every post of the accounts that user follows. If you have 1000 users, multiple of them follow the same people, so you store their data just once and therefore have less data to store per user. But it still scales with the number of users. Big instances are much more expensive than small ones, but per user big instances are cheaper than small ones.
So if someone posts illegal images they just remain on my server even if I "delete" them? That makes me liable to go to prison for hosting one of these things.
There are established procedures for this on Social Media. The owners are supposed to self-report suspected illegal activity and allow the interested organizations to complete their investigation as appropriate. IANAL so make sure to consult with one before implementing any kind of user generated data application.
I didn't got who runs the crawler... I think Mastodon is not that expensive anymore, My 2 blogs are instances on the Fediverse running on WordPress and the ActivityPub plugin. Sounds to me it is easyer to keep my data on a AP network than in a AT network 😉 By the way, one year has passed and there aren't any other instance. Just BlueSky 🤷
Ok! Got it on the comments: "Crawlers are the responsibility of app view providers just like google and open ai create crawlers that scrape and present data for their services" Looks kind of centralized... I got how ActivityPub works, but I think I didn't understand this layer...
There are actually lots of PDS servers! It’s decentralized personal data but centralized application and discovery for users who just want to use the app and not worry about where it’s hosted
Thanks a lot for taking the time and walking us through this complex topic. It's a very good starter to get into a comparison of the protocols.
At 17:08 you start talking about how data is pulled from a PDS into an application indexer/craeler “in ActivityPub”…. I think you meant to say in “AT”…. But otherwise, thank you for the clear explanations.
Yes, definitely a PDS is part of AT protocol, not ActuvityPub. Thanks for the correction
I love the fact that you can't unlike something ! More like a feature than a problem
I was very excited when I heard of ActivityPub with the recent Reddit mess, but as I research more, I cannot stop feeling just confused. It just feels incomplete to me, the integrated Object support for example is extremely basic, and while it is very easy to modify and extend but the more you do it the more it stops being compatible with other instances implementations. You cannot browse Lemmy through Mastodon for example, or even if they are very similar, Kbin and Lemmy have compatibility issues.
It really does feel more like a framework for a protocol rather than an actual usable piece of software that could power the "future of social media".
What pains me the most is that even though this "instability" is obviously an issue, I feel like all of this could have been avoided with some better communication and stronger conventions, even some stricter rules, but now with so many different implementations and some of them becoming more and more alienated from one another it feels like we are just in too deep and the entire point of the protocol seems lost to me.
I really hope ActivityPub works in some way, at least set an alternative to regular social media, but I simply cannot see it as a replacement.
Compatibility between networks comes down to data structures, not how the data is sent between servers. Twitter, Google+, and facebook all let you export and “own” your data but there’s no way make that data compatible and import it between networks.
Actually, Mastodon has partial support for Lemmy threads: you can read them, they just don't always work properly. That's planned to be fixed in an upcoming update.
i dont think it'll replace regular social media, and it doesn't really have to. activitypub will likely run parallel, each catering to different users.
Because youre only familiar with traditional social media, thats why transition is different
@@JustinGarrisonwell the protocol shares the data structure in some way. The internal data structures of implementations can be different, but if they can be communicated through a common protocol the implementations can be compatible, no?
In the end it's a question of how easy it is to map the application user-facing behavior to the protocol, and how much the application designers care about interoperability in their ecosystem.
Threads certainly won't care very much about interoperability with mastodon i think.
Will bluesky maintain a close match between application layer features and protocol layer, and ensure high interop with other implementations that they do not develop? We'll see.
Nice presentation. Thank you!
Thanks man, I'm developing something and it needed a backbone like AT Protocol but I needed a good run down. This was perfect. Namaste brother
Great high-level overview. What is super exciting is that this architecture plays well with other protocols. How the PDS is stored and indexed is an implementation detail. I can see eventually people storing their PDS on multiple nostr relays for example.
How do nostr relays work? I’ve never used it or looked into their architecture
I didn't understand much of what you described even as I've spent alot of time in tech but have moved more into management but i appreciate you guys covering these new protocols and technologies, so we aren't completely aloof when these terms pop up in meetings.
I wonder how you guys learn these things so fast
I don’t know about other people but for me I usually learn by using the tech. I wouldn’t say this was “fast” because I started learning activity pub a couple years ago and took over a month to make something that worked
So you mentioned that within the PDS you cannot remove data and its essential logged in its history forever.
If I own the data in my PDS, can BlueSky for example see what I liked or disliked, if I own the data, can they view the entire history of it, can they access that and use it? If so, how do I own my data, if its public...?
Hope the question makes sense!
---
Also thank you for posting the video, I started learning about Federated Protocols today as a fun little Saturday Activity and this is really helpful in understanding the underlying structure of how ActivityPub and AT Protocol work. Super engaging and fun to watch :)
Glad you found the video and thank you for the comment. Right now everything in AT protocol PDSs is public. Some things are unlinked/ignored at the application crawler layer. It’s the reason why Bluesky doesn’t have DMs. Mastodon doesn’t (yet) have private DMs either because admins can see all messages.
Both protocols are working on creating private messages and deletable content but it’s still a work in progress.
@@JustinGarrison Actually Mastodon has DMs. Yes, admins can see all messages. If you DM someone at Instagram, twitter or facebook, admins can as well see all the messages. Having E2E encryped messages is not a requirement for DMs. Even in Telegram (if you don't activate E2E encryption specifically for your chat) all the messages can be read by the admins. So with ActivityPub you can say "just show it this people" and then just these people + the admins of the instances of these people can see it. But still better than completely public.
There are many things in this video, that are wrong.
- ActivityPub doesn't work like RSS. In the opposite, it works more like E-Mail. When I post something, and you follow me, I send my post to your inbox. And from there your application can present it to you. If you like it, you send that like to my inbox. Instead we could have send E-Mails. RSS on the other side doesn't send anything. If I post something in an RSS feed, you have to ask my server for updates. Actually that's how you described how the At Protocol works. There you have a server with your data and others have to crawl it from there, right? So if you want to stay up to date, you call it maybe once very 5 seconds? While with ActivityPub you push it once to the follower's inbox and that's it. Also as ActivityPub does it, the post is now on both servers.
- You are right, that a lot of servers talk to each other. But you are wrong with the scaling. There is no issue with scaling. It works similar to email, and emails scales very well over different servers. If you run a server, you don't have to configure all other servers. It's just, that your users connect with other users and they exchange messages. So your server is just sending data to other servers, if your users do something, like post, follow, like, etc. Other servers only send your server data, if someone on the other server did something, that effects your user. Else no data needs to be exchanged. So the size of the server depends on the number of users you have and how active they are.
- You explain instance blocking as something negative. It's actually a big feature of ActivityPub. The most important thing of a social network to work well, is good moderation. Without that you are flooded with advertisement, hate, porn and other stuff, you might not want to have.
- It's not true that with ActivityPub you can not move posts. You can implement that. It's not a problem and Mastodon has that feature in their Backlog. The problem with it is moderation. Maybe a user is coming from another server to my server and I have rules on my server about the content. But when I allow them to copy all their post onto my server, I will probably also copy posts I'm not allowing. So I would have to moderate thousands of posts. Also someone could do that maliciously and import posts to reduce the reputation of my instance, saying "look at all the posts here, that are hateful, this is a bad instance", but they have just been imported. So maybe as an instance you want to mark them as imported. They haven't solved such questions, so they didn't implemented it yet, but it will come eventually.
- Sure, an attacker could take over an instance and manipulate stuff. The same thing can happen with the AT-Protocol. I don't see a difference there between the protocols. Somewhere the data is stored and that can be manipulated, if a hacker comes into that system, whether it's a PDS or ActivityPub Server.
- You are wrong with where images are stored. I don't know the AT Protocol so much, but for ActivityPub it's not necessarily the case that they are stored somewhere else. With Mastodon they are stored on your instance, together with your posts and Mastodon also stores images and stuff from other instances as well. So if you follow someone, all their images are stored on my Mastodon server as well. I think probably for privacy reasons, because I the other instance would know, when I load the images. Maybe to keep a good performance, I don't know. It seems to be a waste of resources for me. So for ActivityPub it depends on the implementation, but can be within the server itself.
- 14:09 Well for ActivityPub you can do the same. So PeerTube does video and Mastodon makes microblogging and Pixelfed pictures. But you can implement an ActivityPub server that can post videos and microblogging and pictures. It's just different content you publish over the same protocol. And they can speak with each other. There is no problem to implement an ActivityPub server, that is completely agnostic to the fields and implement clients separately that have different views or different use cases. Also the existing servers already work together. You can follow someone on Pixelfed from your Mastodon account and see their data. So having the separation of storage and functionality already in the protocol is kind of a smart move of the AT protocol, but similar architectures can be build on top of ActivityPub, without any problems.
- You say that the crawlers in the AT Protocol would scale better than ActivityPub. How is that the case? As you explained, when I push something, it's added to my PDS. So the crawler has to ask my PDS "hey dude, is there new content?". How often does the crawler do that? Once an hour? Then it needs an hour until my post is visible for other users. So let's assume there is a big event, like a football game. And I post something about it, I want others to see it right away, right? So with ActivityPub my server pushes it to my followers and they can see it in less than a second later. With the AT protocol, the crawler has to ask the PDS of all the users all the time, right? So it has to ask my PDS "hey dude, is there new content?" maybe every second? 86400 times a day? And for a million users, this crawler has to do 86400000000 requests every day? Or do they accept a delay and just load the data every minute? Or is it just active, if I load data on my client? So let's assume I follow 500 people. So then I open my client, and that client asks the crawler for data, the crawler then asks the 500 PDS of the people I follow, if there is something new and then presents it to me? Doing 500 requests needs a lot of time, so I have to wait a while, until data pops up in my client? Both variants don't scale. So either it works differently from what you presented or it just works because bluesky has direct access to all the data and can optimize it. But it doesn't sound scalable, while ActivityPub totally scales. Everything that happens in ActivityPub follows an user interaction. So there is no polling and things like that, that could be a problem for scaling.
Have you ever run an email server or mastodon instance with more than a few users?
@@JustinGarrison no, why are you asking?
Instance blocking is not part of the ActivityPub spec, not sure where you got that. How is he wrong about scaling? When ActivityPub instances make duplicates that’s not efficient
@@Cloudymindxii blocking is in the hands of each implementation. It doesn't have to be part of the specification.
About the copies, if you don't have a local copy, you have to ask all servers every time a user updates their stream. Calling 100 servers each time I request updates doesn't scale, too. So what's the alternative? They don't have to duplicate content forever. Just for the recent posts it makes sense to keep a copy until it's download to the client. It's like email, instant messengers, etc. You keep a message of the messages at least until they are downloaded.
Another protocol perhaps worth looking at for comparison is XMPP. Older and battletested for instant messaging but also voice/video and presence.
XMPP was great until google killed it
Posts and stuff not transfering over is a very relative concept, most AP implementations allow you to export / import your data, so if you had 10k posts on server 1, you can migrate your account, export your data, and import it in the new server, sometimes the timestamps will be wrong, but at least the posts are there...
As for media not being in the server itself, in AP, most of the time, it is. Most instances actually do host their media in the same server, because most instances are people owned, and we generally hate big tech companies such as Amazon, so we are never going to store our data on their servers, the whole point of decentralisation is to keep data in OUR servers, not the cloud (someone else's computer)
Is import a new feature? It wasn’t an option when I ran a server. The only option was a db import which caused problems for multi user instances
@@JustinGarrison Honestly I don't know, I don't think so, but then again, I don't use Mastodon, so I can't really tell you how long it has been in it or even if it is a festure, but it 100% is an option in Misskey at least...
Also Mastodon plans to integrate a migration of the full post history to the new server. But there are some tricky questions. Malicious users could use that to import posts that violate the rules of the server. Also there could be a couple of GB of posts. So importing so many things at once may cause problems to the instance administrators. So there need to be ways to regulate it. Mastodon hasn't found a good solution for that so far. But anyone can implement that to their software, like Misskey does.
@@Duconi There is a solution to that, private, or controlled sign up instances... Most instances won't allow anyone who stumbles upon them to sign up. That's a way to avoid malicious users signing up. Decentralized moderation is the most effective kind of moderation.
Maybe. I think they have thought about it a lot and maybe it doesn't fit to the way they want their software to be used.
What do you mean by decentralised moderation?
ActivityPub may be more stable but AT protocol is clearly more advanced and clearly what would solve the huge problem we are having at the moment with walled gardens that became obvious with the Twitter disaster
Really nice explanation!
I understand that you dont need to get all the traffic from threads, If you get only what people are following there will be no need to block them
The most important feature will be interoperability. For example, having the same data (friends, posts, chats) on META and Agora Social. If I post on Agora Social, the same post can be read/interacted on META and Agora Social.
What's agora social? By meta do you mean Facebook?
Activitypub is supposed to allow interop. Thread users should be able to see and interact with users from federated mastodon/lemmy/... Instances, in principle.
One variable is how instances federate, and another is how application-level features translate to the protocol level in a way that other federated instances support.
@@schok51 I'm creating a voting app called agora vote so I egoistically made up an example inspired by my project.
Halfway through the video , and awrskme man keep it up
I truly REALLY appreciate your time and effort in presenting these topics and comparing and contrasting these two protocols in particular. But I'm confused and frustrated on a whole 'nother level about them (NOT YOU, them): So they're going to DECENTRALIZE (yea!) social networks by ...CENTRALIZING them on yet another server?!?! Does anyone actually build real APPLICATIONS anymore? Or is EVERYTHING always MY DATA on somebody else's SERVER?! Are we truly unable to create networks that simply facilitate the connection of my computer to my family and friends' computers? Yanno, a actual SOCIAL NETWORK?! i REALLY think we're still totally misusing the internet and WWW tech stack, and I think we're stuck thinking that way because we've been brainwashed by Big Tech firms that that's the way it has to work. From their perspective, they're right, it's the only way THEY can profit from ME communicating and sharing with MY FAMILY AND FRIENDS, and from 'allowing' me to discover new distant/near virtual friends who are content creators whose content and POV I want to experience. Can we TRULY not DO BETTER?!
I'm about ready to go back to dial-up BBS if necessary. I KNOW I can secure that and use it. Did fine with it throughout the late 1970's and 1980's and through a fair bit of the 1990's. Yeah, it's gotten that bad today.
Who hosts the crawler? And where does the crawler store the data?
Crawlers are the responsibility of app view providers just like google and open ai create crawlers that scrape and present data for their services
@@JustinGarrison so this is more like search engine than a native social media protocol
WoW, the linkerd looks neat !
Are there any open alternatives to ActivityPub and At?
Activity pub has a lot of implementations for different apps/networks, but there’s no other widely used protocols I can think of
Yes, Diaspora for example has their own protocol, that is also supported by Hubzilla and Friendica. There is the DFRN protocol which is only implemented by Friendica, I think and there is the zot protocol spoken by Zap and Hubzilla. But except Diaspora, I think they all also speak ActivityPub now, and there is a lot of new software that only speaks ActivityPub, so I think if a social network isn't speaking ActivityPub, they will have a very hard time to establish themselves.
Yes, Nostr
Fantastic video ❤
implementing AP myself, and a big roadblock for me is authentication. I initially thought AP would provide a way to authenticate against another server, but this is false. From my understanding, AP is only for defining common social activities. All the authentication, algorithms, and storage are up to you to build. So, IMO AP is not a solution to anything. It just makes it slightly easier to share data with other servers. Someone, please correct me where I'm wrong.
Where things get muddy for me, is the spec is abstract enough that the federation could totally start including auth as part of the spec. All they would need to do is include 'instructions' in the profile resolved by webfinger.
A new model of content creation /storing has to be considered - not technically, but socially/culturally - creating evergreen content and creating 'time-constrained' content and being able to technically flag which is which, so servers know what to auto-delete after 30 days, or whatever the server chooses. There's no way decentralization can scale by allowing the internet to remember everything, already we're seeing TH-cam publicly straining with their move to disallow ad blockers, Twitter obviously, and fediverse admins. Deletion needs to be taken seriously. Otherwise it'll have to move to charging users by their data size+calls to access the data, which will never allow true public adoption of decentralized protocols. The more I think about it, the more it makes sense for admins to auto-delete posts/content older than 30 or 180 days.
thank you for explaining so well
So, ActivityPub is expensive because the volume of data transferred from server to server when servers have thousands of users.
I would think an implementation that is intended for a single user instance would mean that the costs could be distributed equitably. 1 server with 1000 users costs $100.00 per month, 1000 instances with 1 user, each user pays some fraction of this to, host/own/secure their own data.
Implementing something like this using a serverless infrastructure could keep costs very low per user.
Users with a ton of followers and posts would get more traffic.
Check out wildebeest from cloudflare. It’s a serverless implementation based on their services. It costs a minimum of $10/mo because you have to pay for a higher usage tier of their services
That's kind of true, but not fully. Small ActivityPub instances cost way less than big ones, but it's not 1 user 1$, 1000 users 1000$. One reason is, that servers usually cost money independent of the usage (except you implement it in AWS lambda or something similar, where you pay per request, so you are right). So a small server costs maybe 5$/month. So if their resources are enough to handle 10 users but only one uses that server it still costs 5$/month. But you are right, with serverless infrastructure, that isn't such a big factor.
The other factor is data. If you have 10 users and each follows 100 people, maybe some of them follow the same person. And if that person publishes something, your server has to store it once instead of multiple times. So with more users there are more users that follow the same persons, while when each user had their own server, the data had to be stored more often. This is especially important for Mastodon, who decided to not just store the post locally, but also the media files. So even if you use serverless infrastructure, if you have it for 1 user, you have to store every post of the accounts that user follows. If you have 1000 users, multiple of them follow the same people, so you store their data just once and therefore have less data to store per user.
But it still scales with the number of users. Big instances are much more expensive than small ones, but per user big instances are cheaper than small ones.
So if someone posts illegal images they just remain on my server even if I "delete" them? That makes me liable to go to prison for hosting one of these things.
I’m not a lawyer but image caching has got people in trouble in the past. Multiple Mastodon servers have shut down due to legal concerns.
There are established procedures for this on Social Media. The owners are supposed to self-report suspected illegal activity and allow the interested organizations to complete their investigation as appropriate. IANAL so make sure to consult with one before implementing any kind of user generated data application.
I didn't got who runs the crawler...
I think Mastodon is not that expensive anymore, My 2 blogs are instances on the Fediverse running on WordPress and the ActivityPub plugin.
Sounds to me it is easyer to keep my data on a AP network than in a AT network 😉
By the way, one year has passed and there aren't any other instance. Just BlueSky 🤷
Ok! Got it on the comments:
"Crawlers are the responsibility of app view providers just like google and open ai create crawlers that scrape and present data for their services"
Looks kind of centralized... I got how ActivityPub works, but I think I didn't understand this layer...
There are actually lots of PDS servers! It’s decentralized personal data but centralized application and discovery for users who just want to use the app and not worry about where it’s hosted
Wouldn’t Web3 (blockchain decentralised social media) solve the Acitvity Pub issues?
Blockchain is a very slow database. How would that help?
8:30 ok cya. NEXT!