10 ms·

ActivityPub: a federated social web standard

185 points by paroneayea 9y ago

NoGravitas 9y ago
This is neat stuff. I see immediately how it interacts with things like Mastodon and MediaGoblin. I'd like to see how it could be made to interact with IndieWeb stuff. Particularly, how minimal could you make an ActivityPub server and still have it federate with the things you want it to federate with?
- floatboth 9y ago
  Hopefully someone will make a brid.gy type thing that would just convert ActivityPub server-to-server notifications to Webmentions…
devrandomguy 9y ago
So, about that federated DELETE operation. In a decentralized network, we can't unilaterally delete a shared piece of content; that is one of the main features of decentralization. Even providing that verb seems kind of deceptive to me; it implies that content that enters the network, could conceivably be purged, which will affect how people use the network. Perhaps DISOWN would be a more accurate verb, especially if it would only be accepted from the original owner.
- HerraBRE 9y ago
  If the social contract says "delete things when you see a delete message", then that's useful in a federated environment. Only bad actors will disobey and they will have to modify their software in order to do so. This doesn't provide absolute protection against bad actors, but since most bad actors don't own a time machine, it reduces the scope of the harm they can enact. Consider the adversary "angry ex-boyfriend." Let's assume he wasn't always angry and isn't a sociopath. By the time he has become angry, the sensitive posts have already been deleted. This makes a difference in real life to real people. There is indeed a user-interface concern, to not over-promise to the end-user. But that doesn't justify leaving such a useful thing out at the protocol level.
  - nercht12 9y ago
    >> most bad actors don't own a time machine You mean besides me, of course. XD EDIT: It's a joke people, for Pete's sake.
    - devrandomguy 9y ago
      Actually, this is a real issue. For one, there is the Wayback Machine, which could very well see increased usage and mindshare as legally mandated content takedowns increase. For another, if, say, Facebook wanted to harvest data from this network to create shadow profiles and flesh out missing patterns in their analytics, then they could easily follow everything, keep the raw data/content internal, and never develop the ability to retroactively un-analyze that data when a delete request comes in.
      - HerraBRE 9y ago
        This is a legitimate concern. I would not put it past Facebook (or other businesses which are addicted to harvesting user data) to behave badly against networks like this. However, for the sake of their reputations they'd still probably do it quietly, which means many of the person-to-person attacks that deletion protects against would still be thwarted. This is a problem the same way Facebook's privacy controls are a problem. Facebook themselves are not bound by them, but they're still useful if you want to protect your data from other users of the platform. And FWIW, I think most of the big crawlers respect robots.txt - this is the same sort of thing.
  - beagle3 9y ago
    > Only bad actors will disobey and they will have to modify their software in order to do so. I have an hourly bup backup for each of my servers, that goes to a backup host. I am not a bad actor, have not modified any software, and yet if I run an activityhub server I will have a complete timeline at 1hr granularity, so basically anything not deleted within minutes of posting. (Considering a switch to borg backup when I have the time to really evaluate it)
- cookiecaper 9y ago
  No, I think it's important to retain mutability. Anything you post on the internet now functions the same way; everyone who has viewed it received a copy, and there's no way to ensure that the content is actually gone from everyone's machine; it probably exists in the browser cache of most recipients, etc. However, I think one of the big things that cryptonerds and other people deeply involved in developing this type of technology overlook is that most people don't want a system that tells them "good luck retracting anything you ever publish". Integrating this as a "feature" is actually an active barrier to adoption. Yes, it's true that you can't ever guarantee all copies of something have been destroyed after they've disseminated, but you can still provide the facilities necessary to signal that the content owner wants that to happen, and create an expectation that blessed clients will observe that signal internally. We need to provide mutability at least on par with the current experience if we expect one of these alternate social protocols to pick up steam. These are popping up like flies recently, and most overlook this.
- paroneayea 9y ago
  So, I'm co-editor of the ActivityPub spec, hi! And yes, there's both reasons to want a Delete operation and to be skeptical of it! Reasons to be skeptical of it: well there's the obvious ones, you might want to hold on to some content coming your way and lots of people are disappointed to see things disappear. Mutating networks have some dangers for sure. Reasons it to want it, or that it's there: well, this is how all the existing federated social networks work. ActivityPub was designed in the context of standardizing basically something that projects like Mastodon, Diaspora, MediaGoblin, GNU Social, etc can use. And that is how things work now... mutation and federated deletion has been part of the existing federated social web for a decade. And we're trying to build something people can hook into their existing systems. People may also change their minds about things. Should they have the authority to remove their own posts? An open question, but at the very least, whether a server removes the content or not, a Delete is a request to do so across the network. However, yes, there is an alternative structure one can imagine for these things, and that's something a bit closer to something git-like in the way that branches point at commits, but may change at which commit they point to over time, but the commits themselves never change. That's a desirable thing to explore, and I've blogged about it: http://dustycloud.org/blog/an-even-more-distributed-activitypub/ http://dustycloud.org/blog/an-even-more-distributed-activity... And we're even looking at exploring it, possibly, in the Social Web Incubator Community Group: https://www.w3.org/wiki/ActivityPub_extensions#Possible_future_extensions https://www.w3.org/wiki/ActivityPub_extensions#Possible_futu... BTW, if you're interested in such things, the community group is open to everyone and is hosting weekly meetings https://www.w3.org/community/swicg/ https://www.w3.org/community/swicg/ and we'll be hosting a meeting next week https://www.w3.org/wiki/SocialCG/2017-05-31 https://www.w3.org/wiki/SocialCG/2017-05-31
- TazeTSchnitzel 9y ago
  Practical and legal concerns make such an operation a necessity. Of course it's not guaranteed to work, it relies on trust, but you can't make a system intended for real-world use where you can't at least attempt to delete things. Additionally, though the technology can't force other instances to delete things, other concerns perhaps can. Consider the potential legal implications of deliberately ignoring delete requests.
devrandomguy 9y ago
Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. It also makes it hard to try out new protocols side by side, like IPFS.
- blowski 9y ago
  A URL always includes the scheme. `http://www.example.com/1/ http://www.example.com/1/ ` and `https://www.example.com/1/` https://www.example.com/1/` could represent different content. If you want to change the scheme but keep the old links working, you need to redirect from the old to the new.
  - Filligree 9y ago
    That is the definition of a URL, but not a law of nature. If these keys would be more useful with the scheme being implicit, then perhaps they shouldn't be URLs.
- cat199 9y ago
  > This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. While someone else pointed out the rest of the URL could conceivably point to different content, in practice, it seems like most deployments have a 1:1 correspondence and will redirect from http:// http://(.) to https:// https://(.) when SSL is deployed so this is not so critical for the http(s) case imho..
deft 9y ago
Cool, open standards are a good thing :) good discussion going on here: https://github.com/w3c/activitypub/issues/ https://github.com/w3c/activitypub/issues/ if anyone has questions on the protocol or just doesn't understand some of the writing.
j4pe 9y ago
I really like the idea of a social web standard. This seems like a very constricting protocol, though: the one-to-one correspondence between a user and a server means I need to individually post my activity to the "inbox" of everyone who wants to read it (or they poll my "outbox" - I'm not sure). Not a recipe for an efficient system. It's called ActivityPub, so this was clearly a design decision to meet the goal of being decentralized. But I probably wouldn't implement this standard in a project unless I modified it a bit so that many clients could share a server.
- Jaruzel 9y ago
  There's JSON examples that include following/followers lists. I'm guessing that you could POST to that list, and the backend server takes care of forwarding it on to your followers.
- paroneayea 9y ago
  There's a public delivery mechanism where if many people are on the same server, and its a public post (eg Twitter style messages, etc) it can be delivered to a shared public inbox https://www.w3.org/TR/activitypub/#public-inbox-delivery https://www.w3.org/TR/activitypub/#public-inbox-delivery That way the receiving server can only get POST'ed to once and distribute to the appropriate followers. Of course, for more limited distribution posts, you still have to distribute individually, but that's no different than how email works.
- epeus 9y ago
  Have a look at the related w3c spec WebSub that is designed to deal with this issue: https://www.w3.org/TR/websub/ https://www.w3.org/TR/websub/
  - detaro 9y ago
    Which many may know as Pubsubhubbub, with only minor changes and a new name. (Which is a good thing: no need to make up a new protocol if there is already one in the wild that works)
  - clacke2 9y ago
Jaruzel 9y ago
I like this. Very Much. Adding 'Build ActivityHub test server' to my ever growing to-do list! If we build it, THEY* will come. *Everyone else, obv.
benwerd 9y ago
ActivityPub is awesome, and I'm excited that it's reached this stage. Looking forward to the core Known platform supporting it.
- praveenster 9y ago
  Adding a link to Known to get more context regarding comment above: https://indieweb.org/Known https://indieweb.org/Known https://withknown.com/ https://withknown.com/
- deleted 9y ago
  [deleted]
- clacke2 9y ago
  In general, it would be interesting to see to what degree people manage to build bridges between the IndieWeb and the ActivityPub web. MicroPub and ActivityPub grew out of the same working group, because the two camps couldn't find shared ground. I don't know if they managed to get a decent mapping between ActivityStreams2 and Microformats2 at least.
bct 9y ago
We know how to build protocols for federated systems - there must be at least a dozen serious efforts at federated social media by now. What we don't know (or what we've forgotten) is how to get people to use federated systems.
- paroneayea 9y ago
  It's tricky, though people are using them. Mastodon probably is seeing the most success at the moment. Over half a million users by current estimates. Not everyone who signs up stays around, but there's still quite a bit of retention. We could do better. We need to make these things easier to host and deploy though. Having worked on MediaGoblin for many years now, I've found the most depressing part of it is that not only is it hard for people to start hosting things, it's even harder for them to keep it running... and it's not just MediaGoblin; you'll find this of most social network things. Most especially, people become afraid to upgrade their systems. I'm hopeful that systems like Guix will help in that regard, but that's a whole direction to explore itself: https://media.libreplanet.org/u/libreplanet/m/solving-the-deployment-crisis-with-gnu-guix-f8fd/ https://media.libreplanet.org/u/libreplanet/m/solving-the-de...
  - dmd 9y ago
    > Over half a million users by current estimates For context, that's 3 days' worth of Twitter signups.
- bluetwo 9y ago
  Yes. This seems to be a classic two-sided market problem. Developers won't flock to it unless there is a critical mass of users. Users won't flock to it until there are widely used and understood tools that are better than they have now. https://en.wikipedia.org/wiki/Two-sided_market https://en.wikipedia.org/wiki/Two-sided_market
smarx007 9y ago
The standard is awesome and looks well-designed. The biggest issue is that it was lead solely by the people around Mastodon/Pump.io/Mediagoblin. While not a bad thing per se (on the contrary, it shows a commitment to a free internet), it means that there is little chance for it to penetrate the general (social) networking scene (Facebook, LinkedIn, Twitter, VK etc.). Did you try reaching out to each of those major social networking websites to offer collaboration on this standard? P.S. I understand that ActivityPub represents a radical shift from the centralised social networking, but if I remember correctly Facebook, Google and IBM previously collaborated on open widgets and related functionality until the efforts fell apart: https://github.com/OpenSocial/spec https://github.com/OpenSocial/spec
- shopkins 9y ago
  I would argue it's also, uh, not in their business model whatsoever to support efforts like this (thinking Facebook especially). Better to develop the spec and forge on now, or we'd be waiting around for a long time.
- paroneayea 9y ago
  We did reach out to both all the major centralized social networks and also all the distributed social networks. The major social centralized networks didn't seem interested in participating in this round, but they were welcomed and encouraged to become part of the group iirc.
- tomphoolery 9y ago
  > Did you try reaching out to each of those major social networking websites to offer collaboration on this standard? What possible benefit would it give companies whose entire business value revolves around their data...to just give that data away to anyone? Here's what I learned from working on the DIASPORA* project: The only people that federated/distributed social networking benefits are the 1% of nerds who know how to use it. Everyone else is hopelessly, and willingly, attached at the hip to their social network of choice. Most of the issues or feature requests fell into the following two categories: 1.) I need $FEATURE otherwise I can't use DIASPORA* at all. 2.) Why doesn't $FEATURE in DIASPORA* work like /Facebook|Twitter|Google/? If we made it work exactly like that, regardless of the fact that it makes no sense on a distributed network, we'd be able to actually compete with a $100bil social network! Wow! Both of these are pipe dreams. With #1, the person is convincing themselves that they want to use D*, but in reality they just want Facebook without Facebook actually owning their data. #2 is the notion that a company like Facebook or Google, who both simultaneously and independently got rid of the last remaining "interoperable standard" in their business: XMPP. Yes, XMPP...once the golden boy of federated discussion platforms...has been totally deprecated by the top two implementors. Why? Because building their own, centralized IM service is not only more lucrative, it's also a lot easier and less expensive. The fact that anyone actually sat down and took the time to build specs for federated social networking is a miracle to me...considering there's practically zero business value in it.
max_ 9y ago
I think It looks more like a mashup of Facebook & Twitter. It would really be good is some of the actions e.g liking, following, were more generalized. For instance, instead of "like" you could have an entity called "Response" that could refer to a comment/like/upvote/downvote etc
fergazen 9y ago
Interesting standard. I'm also working on an app that you would categorize as an open source social media platform: SubNode -> http://sbnode.com http://sbnode.com
windlep 9y ago
Small section about how Spam should be handled somehow by a server. Sigh. How about we build a federated spam/harassment prevention system first? I have little hope that a spec not designed to reduce/stop harassment up front can have it bolted on later successfully.
- ForHackernews 9y ago
  It's only a "candidate" so far, maybe you can add some suggestions?
  - graphememes 9y ago
    I believe they did give a suggestion, to build it before making the assumption that it works.
    - deleted 9y ago
      [deleted]
    - placeybordeaux 9y ago
      It might be higher value to submit a github issue: https://github.com/w3c/activitypub/issues?utf8=&q=is%3Aissue%20spam https://github.com/w3c/activitypub/issues?utf8=&q=is%3Aissue...
      - graphememes 9y ago
        Why haven't you done it then?
    - JeremyBanks 9y ago
      It has already been built.
- paroneayea 9y ago
  Well we certainly consider it an important aspect! But also, as said, we were standardizing the existing set of federation functionality currently implemented in the federated social web. But the Social Web Incubator Community Group has made anti-spam/anti-abuse stuff part of our mission, but that's hard stuff. ActivityPub does include federated blocklist support, but I think it's not enough. I've written about possible directions though: https://dustycloud.org/blog/possible-distributed-anti-abuse/ https://dustycloud.org/blog/possible-distributed-anti-abuse/
avivo 9y ago
Social networks function in the context of society. Which is messy. Developing a system that doesn't have very harmful failure modes is not easy. And if it's a federated standard, there is no easy way to fix it after the fact. I'd recommend that anyone working on something like that (or really any social network) read this: https://www.twitterandteargas.org/ https://www.twitterandteargas.org/ Evan Williams, a Twitter founder recently said: “I thought once everybody could speak freely and exchange information and ideas, the world is automatically going to be a better place. I was wrong about that.”
crudbug 9y ago
The BuddyCloud [0] project also came up with a standard proposal. Is this related to that work ? [0] https://github.com/buddycloud/buddycloud-xep https://github.com/buddycloud/buddycloud-xep
- clacke2 9y ago
  Not at all. ActivityPub comes from pump.io, which was based on the experiences with OStatus. BuddyCloud is a parallel track to OStatus, possibly inspired by the OStatus predecessor OpenMicroBlogging, but I don't know that. Both tracks came about around the same time a decade ago.
eevilspock 9y ago
I don't see any mention of encryption in this standard. Are all messages public? I'd like to see this using public and private keys so that it is guaranteed only intended recipients (e.g. people on my friends list) can read my messages. This is especially important given the federated nature of this.
Mike101 9y ago
"They just want to be in control of their data" sure .. but that's not a problem massive centralised services can solve. If you put your data on someone else's computer then who REALLY has control of it? whom you trust is of course your choice and theres no "one size fits all" re any of it. re: opensocial That wasn't about federation. the scope of it was closer to webapps. remember Google Gadgets? it was pretty much based on and extending that. btw I think from memory Myspace was part of that group and implemented some parts of the opensocial spec. I don't remember Facebook being involved with Opensocial.

185 points by paroneayea 9y ago

This is neat stuff. I see immediately how it interacts with things like Mastodon and MediaGoblin. I'd like to see how it could be made to interact with IndieWeb stuff. Particularly, how minimal could you make an ActivityPub server and still have it federate with the things you want it to federate with?

floatboth 9y ago
Hopefully someone will make a brid.gy type thing that would just convert ActivityPub server-to-server notifications to Webmentions…

devrandomguy 9y ago

So, about that federated DELETE operation. In a decentralized network, we can't unilaterally delete a shared piece of content; that is one of the main features of decentralization. Even providing that verb seems kind of deceptive to me; it implies that content that enters the network, could conceivably be purged, which will affect how people use the network. Perhaps DISOWN would be a more accurate verb, especially if it would only be accepted from the original owner.

HerraBRE 9y ago
If the social contract says "delete things when you see a delete message", then that's useful in a federated environment. Only bad actors will disobey and they will have to modify their software in order to do so. This doesn't provide absolute protection against bad actors, but since most bad actors don't own a time machine, it reduces the scope of the harm they can enact. Consider the adversary "angry ex-boyfriend." Let's assume he wasn't always angry and isn't a sociopath. By the time he has become angry, the sensitive posts have already been deleted. This makes a difference in real life to real people. There is indeed a user-interface concern, to not over-promise to the end-user. But that doesn't justify leaving such a useful thing out at the protocol level.
- nercht12 9y ago
  >> most bad actors don't own a time machine You mean besides me, of course. XD EDIT: It's a joke people, for Pete's sake.
  - devrandomguy 9y ago
    Actually, this is a real issue. For one, there is the Wayback Machine, which could very well see increased usage and mindshare as legally mandated content takedowns increase. For another, if, say, Facebook wanted to harvest data from this network to create shadow profiles and flesh out missing patterns in their analytics, then they could easily follow everything, keep the raw data/content internal, and never develop the ability to retroactively un-analyze that data when a delete request comes in.
    - HerraBRE 9y ago
      This is a legitimate concern. I would not put it past Facebook (or other businesses which are addicted to harvesting user data) to behave badly against networks like this. However, for the sake of their reputations they'd still probably do it quietly, which means many of the person-to-person attacks that deletion protects against would still be thwarted. This is a problem the same way Facebook's privacy controls are a problem. Facebook themselves are not bound by them, but they're still useful if you want to protect your data from other users of the platform. And FWIW, I think most of the big crawlers respect robots.txt - this is the same sort of thing.
- beagle3 9y ago
  > Only bad actors will disobey and they will have to modify their software in order to do so. I have an hourly bup backup for each of my servers, that goes to a backup host. I am not a bad actor, have not modified any software, and yet if I run an activityhub server I will have a complete timeline at 1hr granularity, so basically anything not deleted within minutes of posting. (Considering a switch to borg backup when I have the time to really evaluate it)
cookiecaper 9y ago
No, I think it's important to retain mutability. Anything you post on the internet now functions the same way; everyone who has viewed it received a copy, and there's no way to ensure that the content is actually gone from everyone's machine; it probably exists in the browser cache of most recipients, etc. However, I think one of the big things that cryptonerds and other people deeply involved in developing this type of technology overlook is that most people don't want a system that tells them "good luck retracting anything you ever publish". Integrating this as a "feature" is actually an active barrier to adoption. Yes, it's true that you can't ever guarantee all copies of something have been destroyed after they've disseminated, but you can still provide the facilities necessary to signal that the content owner wants that to happen, and create an expectation that blessed clients will observe that signal internally. We need to provide mutability at least on par with the current experience if we expect one of these alternate social protocols to pick up steam. These are popping up like flies recently, and most overlook this.
paroneayea 9y ago
So, I'm co-editor of the ActivityPub spec, hi! And yes, there's both reasons to want a Delete operation and to be skeptical of it! Reasons to be skeptical of it: well there's the obvious ones, you might want to hold on to some content coming your way and lots of people are disappointed to see things disappear. Mutating networks have some dangers for sure. Reasons it to want it, or that it's there: well, this is how all the existing federated social networks work. ActivityPub was designed in the context of standardizing basically something that projects like Mastodon, Diaspora, MediaGoblin, GNU Social, etc can use. And that is how things work now... mutation and federated deletion has been part of the existing federated social web for a decade. And we're trying to build something people can hook into their existing systems. People may also change their minds about things. Should they have the authority to remove their own posts? An open question, but at the very least, whether a server removes the content or not, a Delete is a request to do so across the network. However, yes, there is an alternative structure one can imagine for these things, and that's something a bit closer to something git-like in the way that branches point at commits, but may change at which commit they point to over time, but the commits themselves never change. That's a desirable thing to explore, and I've blogged about it: http://dustycloud.org/blog/an-even-more-distributed-activitypub/ http://dustycloud.org/blog/an-even-more-distributed-activity... And we're even looking at exploring it, possibly, in the Social Web Incubator Community Group: https://www.w3.org/wiki/ActivityPub_extensions#Possible_future_extensions https://www.w3.org/wiki/ActivityPub_extensions#Possible_futu... BTW, if you're interested in such things, the community group is open to everyone and is hosting weekly meetings https://www.w3.org/community/swicg/ https://www.w3.org/community/swicg/ and we'll be hosting a meeting next week https://www.w3.org/wiki/SocialCG/2017-05-31 https://www.w3.org/wiki/SocialCG/2017-05-31
TazeTSchnitzel 9y ago
Practical and legal concerns make such an operation a necessity. Of course it's not guaranteed to work, it relies on trust, but you can't make a system intended for real-world use where you can't at least attempt to delete things. Additionally, though the technology can't force other instances to delete things, other concerns perhaps can. Consider the potential legal implications of deliberately ignoring delete requests.

devrandomguy 9y ago

Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. It also makes it hard to try out new protocols side by side, like IPFS.

blowski 9y ago
A URL always includes the scheme. `http://www.example.com/1/ http://www.example.com/1/ ` and `https://www.example.com/1/` https://www.example.com/1/` could represent different content. If you want to change the scheme but keep the old links working, you need to redirect from the old to the new.
- Filligree 9y ago
  That is the definition of a URL, but not a law of nature. If these keys would be more useful with the scheme being implicit, then perhaps they shouldn't be URLs.
cat199 9y ago
> This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. While someone else pointed out the rest of the URL could conceivably point to different content, in practice, it seems like most deployments have a 1:1 correspondence and will redirect from http:// http://(.) to https:// https://(.) when SSL is deployed so this is not so critical for the http(s) case imho..

deft 9y ago

Cool, open standards are a good thing :) good discussion going on here: https://github.com/w3c/activitypub/issues/ https://github.com/w3c/activitypub/issues/ if anyone has questions on the protocol or just doesn't understand some of the writing.

j4pe 9y ago

I really like the idea of a social web standard. This seems like a very constricting protocol, though: the one-to-one correspondence between a user and a server means I need to individually post my activity to the "inbox" of everyone who wants to read it (or they poll my "outbox" - I'm not sure). Not a recipe for an efficient system. It's called ActivityPub, so this was clearly a design decision to meet the goal of being decentralized. But I probably wouldn't implement this standard in a project unless I modified it a bit so that many clients could share a server.

Jaruzel 9y ago
There's JSON examples that include following/followers lists. I'm guessing that you could POST to that list, and the backend server takes care of forwarding it on to your followers.
paroneayea 9y ago
There's a public delivery mechanism where if many people are on the same server, and its a public post (eg Twitter style messages, etc) it can be delivered to a shared public inbox https://www.w3.org/TR/activitypub/#public-inbox-delivery https://www.w3.org/TR/activitypub/#public-inbox-delivery That way the receiving server can only get POST'ed to once and distribute to the appropriate followers. Of course, for more limited distribution posts, you still have to distribute individually, but that's no different than how email works.
epeus 9y ago
Have a look at the related w3c spec WebSub that is designed to deal with this issue: https://www.w3.org/TR/websub/ https://www.w3.org/TR/websub/
- detaro 9y ago
  Which many may know as Pubsubhubbub, with only minor changes and a new name. (Which is a good thing: no need to make up a new protocol if there is already one in the wild that works)
- clacke2 9y ago

Jaruzel 9y ago

I like this. Very Much. Adding 'Build ActivityHub test server' to my ever growing to-do list! If we build it, THEY* will come. *Everyone else, obv.

benwerd 9y ago

ActivityPub is awesome, and I'm excited that it's reached this stage. Looking forward to the core Known platform supporting it.

praveenster 9y ago
Adding a link to Known to get more context regarding comment above: https://indieweb.org/Known https://indieweb.org/Known https://withknown.com/ https://withknown.com/
deleted 9y ago
[deleted]
clacke2 9y ago
In general, it would be interesting to see to what degree people manage to build bridges between the IndieWeb and the ActivityPub web. MicroPub and ActivityPub grew out of the same working group, because the two camps couldn't find shared ground. I don't know if they managed to get a decent mapping between ActivityStreams2 and Microformats2 at least.

bct 9y ago

We know how to build protocols for federated systems - there must be at least a dozen serious efforts at federated social media by now. What we don't know (or what we've forgotten) is how to get people to use federated systems.

paroneayea 9y ago
It's tricky, though people are using them. Mastodon probably is seeing the most success at the moment. Over half a million users by current estimates. Not everyone who signs up stays around, but there's still quite a bit of retention. We could do better. We need to make these things easier to host and deploy though. Having worked on MediaGoblin for many years now, I've found the most depressing part of it is that not only is it hard for people to start hosting things, it's even harder for them to keep it running... and it's not just MediaGoblin; you'll find this of most social network things. Most especially, people become afraid to upgrade their systems. I'm hopeful that systems like Guix will help in that regard, but that's a whole direction to explore itself: https://media.libreplanet.org/u/libreplanet/m/solving-the-deployment-crisis-with-gnu-guix-f8fd/ https://media.libreplanet.org/u/libreplanet/m/solving-the-de...
- dmd 9y ago
  > Over half a million users by current estimates For context, that's 3 days' worth of Twitter signups.
bluetwo 9y ago
Yes. This seems to be a classic two-sided market problem. Developers won't flock to it unless there is a critical mass of users. Users won't flock to it until there are widely used and understood tools that are better than they have now. https://en.wikipedia.org/wiki/Two-sided_market https://en.wikipedia.org/wiki/Two-sided_market

smarx007 9y ago

The standard is awesome and looks well-designed. The biggest issue is that it was lead solely by the people around Mastodon/Pump.io/Mediagoblin. While not a bad thing per se (on the contrary, it shows a commitment to a free internet), it means that there is little chance for it to penetrate the general (social) networking scene (Facebook, LinkedIn, Twitter, VK etc.). Did you try reaching out to each of those major social networking websites to offer collaboration on this standard? P.S. I understand that ActivityPub represents a radical shift from the centralised social networking, but if I remember correctly Facebook, Google and IBM previously collaborated on open widgets and related functionality until the efforts fell apart: https://github.com/OpenSocial/spec https://github.com/OpenSocial/spec

shopkins 9y ago
I would argue it's also, uh, not in their business model whatsoever to support efforts like this (thinking Facebook especially). Better to develop the spec and forge on now, or we'd be waiting around for a long time.
paroneayea 9y ago
We did reach out to both all the major centralized social networks and also all the distributed social networks. The major social centralized networks didn't seem interested in participating in this round, but they were welcomed and encouraged to become part of the group iirc.
tomphoolery 9y ago
> Did you try reaching out to each of those major social networking websites to offer collaboration on this standard? What possible benefit would it give companies whose entire business value revolves around their data...to just give that data away to anyone? Here's what I learned from working on the DIASPORA* project: The only people that federated/distributed social networking benefits are the 1% of nerds who know how to use it. Everyone else is hopelessly, and willingly, attached at the hip to their social network of choice. Most of the issues or feature requests fell into the following two categories: 1.) I need $FEATURE otherwise I can't use DIASPORA* at all. 2.) Why doesn't $FEATURE in DIASPORA* work like /Facebook|Twitter|Google/? If we made it work exactly like that, regardless of the fact that it makes no sense on a distributed network, we'd be able to actually compete with a $100bil social network! Wow! Both of these are pipe dreams. With #1, the person is convincing themselves that they want to use D*, but in reality they just want Facebook without Facebook actually owning their data. #2 is the notion that a company like Facebook or Google, who both simultaneously and independently got rid of the last remaining "interoperable standard" in their business: XMPP. Yes, XMPP...once the golden boy of federated discussion platforms...has been totally deprecated by the top two implementors. Why? Because building their own, centralized IM service is not only more lucrative, it's also a lot easier and less expensive. The fact that anyone actually sat down and took the time to build specs for federated social networking is a miracle to me...considering there's practically zero business value in it.

max_ 9y ago

I think It looks more like a mashup of Facebook & Twitter. It would really be good is some of the actions e.g liking, following, were more generalized. For instance, instead of "like" you could have an entity called "Response" that could refer to a comment/like/upvote/downvote etc

fergazen 9y ago

Interesting standard. I'm also working on an app that you would categorize as an open source social media platform: SubNode -> http://sbnode.com http://sbnode.com

windlep 9y ago

Small section about how Spam should be handled somehow by a server. Sigh. How about we build a federated spam/harassment prevention system first? I have little hope that a spec not designed to reduce/stop harassment up front can have it bolted on later successfully.

ForHackernews 9y ago
It's only a "candidate" so far, maybe you can add some suggestions?
- graphememes 9y ago
  I believe they did give a suggestion, to build it before making the assumption that it works.
  - deleted 9y ago
    [deleted]
  - placeybordeaux 9y ago
    It might be higher value to submit a github issue: https://github.com/w3c/activitypub/issues?utf8=&q=is%3Aissue%20spam https://github.com/w3c/activitypub/issues?utf8=&q=is%3Aissue...
    - graphememes 9y ago
      Why haven't you done it then?
  - JeremyBanks 9y ago
    It has already been built.
paroneayea 9y ago
Well we certainly consider it an important aspect! But also, as said, we were standardizing the existing set of federation functionality currently implemented in the federated social web. But the Social Web Incubator Community Group has made anti-spam/anti-abuse stuff part of our mission, but that's hard stuff. ActivityPub does include federated blocklist support, but I think it's not enough. I've written about possible directions though: https://dustycloud.org/blog/possible-distributed-anti-abuse/ https://dustycloud.org/blog/possible-distributed-anti-abuse/

avivo 9y ago

Social networks function in the context of society. Which is messy. Developing a system that doesn't have very harmful failure modes is not easy. And if it's a federated standard, there is no easy way to fix it after the fact. I'd recommend that anyone working on something like that (or really any social network) read this: https://www.twitterandteargas.org/ https://www.twitterandteargas.org/ Evan Williams, a Twitter founder recently said: “I thought once everybody could speak freely and exchange information and ideas, the world is automatically going to be a better place. I was wrong about that.”

crudbug 9y ago

The BuddyCloud [0] project also came up with a standard proposal. Is this related to that work ? [0] https://github.com/buddycloud/buddycloud-xep https://github.com/buddycloud/buddycloud-xep

clacke2 9y ago
Not at all. ActivityPub comes from pump.io, which was based on the experiences with OStatus. BuddyCloud is a parallel track to OStatus, possibly inspired by the OStatus predecessor OpenMicroBlogging, but I don't know that. Both tracks came about around the same time a decade ago.

eevilspock 9y ago

I don't see any mention of encryption in this standard. Are all messages public? I'd like to see this using public and private keys so that it is guaranteed only intended recipients (e.g. people on my friends list) can read my messages. This is especially important given the federated nature of this.

Mike101 9y ago

"They just want to be in control of their data" sure .. but that's not a problem massive centralised services can solve. If you put your data on someone else's computer then who REALLY has control of it? whom you trust is of course your choice and theres no "one size fits all" re any of it. re: opensocial That wasn't about federation. the scope of it was closer to webapps. remember Google Gadgets? it was pretty much based on and extending that. btw I think from memory Myspace was part of that group and implemented some parts of the opensocial spec. I don't remember Facebook being involved with Opensocial.