Live data from Hacker News

ActivityPub: decentralized social networking protocol

w3.org

101–110 of 140 posts

Re: ActivityPub: decentralized social networking protocol

#101

Earlier quoted context omitted.

Please don't say that. We already had such pain from HTTP, FTP, and SMTP not starting with it. If building the next version of internet discussion and sharing, we really need first-class support for encryption.

no, we really don't. Not every tool needs to be equipped for private discussions. ActivityPub and OStatus are used for Twitter-style communication. Those aren't high security communication services.

They turn into security problems in aggregate. For example, the threat to me from actors slurping up social media data to nudge/manipulate people at a large scale is much larger than the threat to me than someone reading my group chats to my friends or a lot of other personal info that is generally considered more private and more in need of high security.

If my personal twitter-style communication got out it would be worse to me than my more private messages, but it is worse to me personally if all the twitter style communication gets out than only my more private messages.

You have to account for manipulative big data risks in your analysis, thinking only about your personal data is an outdated approach.

Re: ActivityPub: decentralized social networking protocol

#102

Earlier quoted context omitted.

Please don't say that. We already had such pain from HTTP, FTP, and SMTP not starting with it. If building the next version of internet discussion and sharing, we really need first-class support for encryption.

no, we really don't. Not every tool needs to be equipped for private discussions. ActivityPub and OStatus are used for Twitter-style communication. Those aren't high security communication services.

Start with the safe and secure option, figure out how to dial it down and open it up.

Doing it the other way around? We literally have 50 years of experience of that being a terrible, terrible idea.

Re: ActivityPub: decentralized social networking protocol

#103

Yeah, let's send my social media data to a bunch of servers automatically through a distributed protocol with no practical means to enforce compliance with privacy settings. But that's okay, nobody ever posts anything on social media that they end up regretting, right?

I'm reasonably secure in my feeling that centralisation isn't the problem.

As much as people far too freely giving up information about themselves online. Decentralisation can work as an anti-censorship measure but I wouldn't expect something I send out over Bittorrent (for example) to remain my personal private info.

Re: ActivityPub: decentralized social networking protocol

#104
post #61

ActivityPub is like JWT. Simple on the outside but complex inside. For example I wanted to implement a simple server to connect to Mastodon. JSON via HTTP, what could be simpler? Actually it's JSON-LD not JSON. But it doesn't matter as JSON-LD is JSON, right? No, as the standard requires normalizing JSON-LD for purposes of signing that includes all of RDF canonicalization, of course the standard do not require it [0]…

HTTP signatures and LD-signatures serve different purposes. HTTP sigs authenticate server-to-server requests, while LD-signatures allow to forward verified messages in the network. The forwarding part is a good extra for UX purposes but it's not necessary for your implementation, you can just stick to HTTP sigs which are really simple. I agree that LD-signatures are very complicated to implement. If you avoid LD-signatures then you don't have to mess with JSON-LD canonicalization either, you can just treat the JSON as simple JSON (though it's still a bit fiddly because a value can often be either a URI string, an array of URI strings, an object, or an array of objects).

Re: ActivityPub: decentralized social networking protocol

#105

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…

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.

Re: ActivityPub: decentralized social networking protocol

#108

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…

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 to level out the playing field. That's why I suggested a way to make it easier for other sw engineers to support it.

Re: ActivityPub: decentralized social networking protocol

#110
post #52
post #48

Earlier quoted context omitted.

That's not true. XMPP can do far more than instant messaging, and it's definitely not complicated (well for a decentralized network and for technical audience of course). For the record I'm the main developer of a XMPP based "social network" project (Salut à Toi), and we are able to communicate natively with others XMPP projects (e.g. Movim) for years (we can share comments like in the video, it's the basis of common…

The problem I've always had with XMPP is that any time I try to do something with it, I get lost in an endless sea of RFCs with no idea of which are important for my use-case (most RFC titles seem fairly jargon-heavy to me). Then, when I go to read an actual RFC, because of the fact that each RFC has some interactions with all other RFCs, they're fairly impenetrable. Is there a document somewhere collecting the most…

It's progressively more functional as you implement each of the two RFCs. If you implement the first (6120: Core) you'll be able to process XML streams. The second brings IM, a friend list, and presence. You can then implement XEPs as you need them.

If your development workflow uses sprints in any form, the format of XMPP documentation is perfect. If you want to implement everything at once, good luck.

Post reply on HN