ActivityPub: decentralized social networking protocol • Hacker News Board

Re: ActivityPub: decentralized social networking protocol

#131

Post by fluxdenuit » Thu, Jan 25, 2018, 3:24 PM UTC

grizzles wrote: post #92

The thought process behind ActivityPub seems fanciful to me. To paraphrase: Here is a spec for something no one currently uses, please take a risk and invest your time to understand ActivityPub, build an impl of ActivityPub, and then build your thing on top of it. Then, if many others also do this, it might have a chance at success. Heed the lesson of OStatus. Open source has killed RFC style development. If the back…

Well, I guess we're wrong then.

At Hathi (https://newguard.icei.org/projects/index.html) we're using ActivityPub as our data exchange protocol.

It's well thought out, and saves us a lot of trouble. It's easier to discuss architecture with something on hand to refer to.

As for the investment of time.. yes, but we figure it'll be worth it. We're not satisfied with any of the current platforms. We want to be able to collaborate without distractions, and we figure others will join us along the way.

Re: ActivityPub: decentralized social networking protocol

#132

Post by [deleted] » Thu, Jan 25, 2018, 4:31 PM UTC

jrochkind1 wrote: post #55

ams6110 wrote: post #51

Earlier quoted context omitted.

Socal media is orthogonal to privacy. If you want to keep something private, don't post it on a social media platform -- or at least, encrypt it out of band before you do.

I don't think "orthogonal" means what you think it means.

[deleted]

Re: ActivityPub: decentralized social networking protocol

#133

Post by zardo » Thu, Jan 25, 2018, 4:50 PM UTC

jrochkind1 wrote: post #55

ams6110 wrote: post #51

Earlier quoted context omitted.

Socal media is orthogonal to privacy. If you want to keep something private, don't post it on a social media platform -- or at least, encrypt it out of band before you do.

I don't think "orthogonal" means what you think it means.

To expand on that... If social media is orthogonal to privacy, then there should be no conflict combing the two concepts to create (privacy + social media).

If they are incompatible, they aren't orthogonal, they are opposed.

Re: ActivityPub: decentralized social networking protocol

#134

Post by treve » Thu, Jan 25, 2018, 5:11 PM UTC

grizzles wrote: post #108

gargron wrote: post #105

Earlier quoted context omitted.

Did you miss the part where a million people use ActivityPub via Mastodon? There are already numerous implementations, such as Mastodon, Hubzilla, Pleroma, PeerTube, Kroeg, and more.

Perhaps I should have said "that no one uses directly". I tried out Mastodon but didn't become a regular user. So I'm just curious, are you claiming a million monthly active users or a million accounts created since inception? A million a month is roughly what serverfault.com gets. If you have 1MAU/month, that's a nice achievement, though it's still 1/130th the market share of twitter. I hope Mastodon keeps growing t…

By that logic no one uses email directly either.

Re: ActivityPub: decentralized social networking protocol

#135

Post by dpc_pw » Thu, Jan 25, 2018, 6:21 PM UTC

stevedekorte wrote: post #109

Federated is not decentralized. If you feel this is a small point, please consider the centralization which has happened with email, jabber, and other federated systems.

Anything web-based is a dead end at this point. There is many, many reasons why any web-based solution will degenerate into centralized system. People behind Urbit got it right. I don't know if Urbit is going to succeed, but the they have pointed out the issue brilliantly.

Re: ActivityPub: decentralized social networking protocol

#136

Post by cuckcuckspruce » Thu, Jan 25, 2018, 8:06 PM UTC

NoGravitas wrote: post #70

cuckcuckspruce wrote: post #40

All of these social networking protocols feel like we're just re-inventing UUCP at a higher level.

I've considered that, as well. I enjoy Mastodon, and am working on another ActivityPub project. But in a lot of ways it's not a significant advantage over Usenet.

Mail over UUCP and Usenet over UUCP are optimized for short(-ish) messages, and deal with packet loss, dynamic IP addresses on remote connections, partial transfers, and synchronization scheduling as part of their implementation.

It would seem to be a good base to build something like ActivityPub on top of.

Re: ActivityPub: decentralized social networking protocol

#137

Post by detaro » Thu, Jan 25, 2018, 9:18 PM UTC

grizzles wrote: post #92

The thought process behind ActivityPub seems fanciful to me. To paraphrase: Here is a spec for something no one currently uses, please take a risk and invest your time to understand ActivityPub, build an impl of ActivityPub, and then build your thing on top of it. Then, if many others also do this, it might have a chance at success. Heed the lesson of OStatus. Open source has killed RFC style development. If the back…

Alternative paraphrase: Here is a spec based on our experiences building federated social networks, here are several implementations of it working together, if you want to join your users to this existing network you can implement it or adapt on of the existing solutions.

If your goal is actually different implementations and not just "an open source project", standards are important. The space was quite fragmented, ActivityPub is a chance to have more stuff talk with each other.

Re: ActivityPub: decentralized social networking protocol

#138

Post by evanprodromou » Thu, Jan 25, 2018, 9:28 PM UTC

kemenaran wrote: post #5

This protocol is a successor to OStatus (GNU Social), and mostly made by the same people. From what I remember, Mastodon switched from OStatus to ActivityPub a few releases ago. In the past they had to extend the OStatus protocol for private messages, which meant some clients may not honor the private status of theses posts. ActivityPub has private messages defined properly in the spec. It seems PeerTube ( https://gi…

That's probably a fair consideration. I and others worked on an intermediate system called pump.io, and the ActivityPub interface is very similar to the pump.io client-to-server API and federation protocol.

The biggest advantages of ActivityPub over OStatus are: JSON instead of Atom XML; a defined client-to-server API; and private distribution, including to contact lists (like Diaspora's aspects).

As someone who has worked on this type of standard for over a decade, I can say that it's the best federation standard I've ever seen, and I've seen them all.

Re: ActivityPub: decentralized social networking protocol

#139

Post by Shoothe » Fri, Jan 26, 2018, 1:13 PM UTC

yellowsir wrote: post #122

daveid wrote: post #106

Earlier quoted context omitted.

With cryptography.

how? in the example the data is not signed, what is stopping a other server from changing the content i posted?

The real world example as used by Mastodon uses signing to protect content but the process is kind of complicated (normalization of json to RDF triples etc.)

Re: ActivityPub: decentralized social networking protocol

#140

Post by daveid » Mon, Jan 29, 2018, 5:18 AM UTC

yellowsir wrote: post #122

daveid wrote: post #106

Earlier quoted context omitted.

With cryptography.

how? in the example the data is not signed, what is stopping a other server from changing the content i posted?

The exact methods of authentication are simply "out of scope" for the ActivityPub standard itself. As far as I understand simply for bureaucratic reasons. In reality there's already agreed upon mechanisms for doing this.

Each actor has an RSA keypair. Server-to-server requests are authenticated using HTTP signatures (that's a different spec), so you know a delivery is legit and on behalf of which actor it is. For messages that are passed directly between origin and destination there is no reason to believe the sender has tampered with the message (SSL is a prerequisite anyway). For messages that are about other messages, such as reblogs, you would not trust the sender, you would look up the message by its ID on its origin server instead. This is always possible because ActivityPub prescribes IDs to be resolveable URIs. There's also another method to verify the authenticity of a passed message, called Linked-Data Signatures (that's a different spec). It's a way of signing JSON inside JSON, it's a bit of a bother to implement though (To make sure the signature works regardless of how the payload is re-formatted or re-ordered in transit, the JSON is "canonicalized" using RDF)