Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ActivityPub: decentralized social networking protocol

w3.org

Post reply on HN
Print view View original

91–100 of 140 posts

Re: ActivityPub: decentralized social networking protocol

#91

Post by fenwick67 »

ChristianBundy wrote: post #66
Crespyl wrote: post #46

Earlier quoted context omitted.

Scuttlebut is, so far, the most interesting decentralized social media tool I've seen. Even Mastodon and Matrix still require a server of some form, while SSB will continue to work offline and via truly local peer to peer connections. The only issue is client support and the fact that I don't have a good sense of the state of development/stability/soundness for SSB. If you (or anyone) has experience actually using SS…

SSB is rock-solid in that the community encourages the use of diverse client and server implementations rather than having a monolithic interface that's meant to do everything. On the other hand, the underlying libraries are opinionated in that they usually use depject and a handful of other tools/techniques that aren't super familiar to those outside the SSB community, which makes it harder to write brand new client…

+1 for the opinionated code bit, the Patchwork (i.e. the client) codebase is very dependent on lots of abstract patterns and libraries.

Re: ActivityPub: decentralized social networking protocol

#92

Post by grizzles »

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 backers of ActivityPub genuinely want people to use it then they should publish a reference grpc microservice porcelain on docker so people can use it from any language, without thinking about it. Otherwise the cost to implement ActivityPub is just too high.

Re: ActivityPub: decentralized social networking protocol

#94

Post by dvt »

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.

If so, he's in good company[1] :)

[1] http://www.washingtonpost.com/wp-dyn/content/article/2010/01...

Re: ActivityPub: decentralized social networking protocol

#95

Post by adamnemecek »

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…

It really hasn’t. RFC is a part of all web standards and even some open source like Rust and React.

RFCs are a sign of maturity of open source projects.

Re: ActivityPub: decentralized social networking protocol

#97

Post by paroneayea »

jeswin wrote: post #7

From my quick read of the spec, server-to-server federation assumes that servers can be trusted. That need not be the case; unless a message is signed it should not be assumed to have come from a specific user. I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). The other question is whether we want server-to-server federatio…

Hi... ActivityPub co-editor here. I linked to it elsewhere in the spec, but my paper at Rebooting Web of Trust addresses some of this: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust...

Currently ActivityPub servers in practice use HTTP Signatures and Linked Data Signatures, so there's a certain amount of proof of the origin of messages there. But in moving towards a much more peer to peer system, we can do even better by stripping out SSL Certificate Authorities and DNS altogether. The paper linked above discusses one path to accomplishing that in ActivityPub using DIDs. Hope that's interesting to you!

Re: ActivityPub: decentralized social networking protocol

#98

Post by Arathorn »

Crespyl wrote: post #46
rakoo wrote: post #17

Earlier quoted context omitted.

> I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). This is exactly what namecoin tried to solve. Buy an identifier, put whatever you want in it. Example: https://nameid.org/?name=rakoo > The other question is whether we want server-to-server federation at all instead of a P2P network like bittorrent. We want something in b…

Scuttlebut is, so far, the most interesting decentralized social media tool I've seen. Even Mastodon and Matrix still require a server of some form, while SSB will continue to work offline and via truly local peer to peer connections. The only issue is client support and the fact that I don't have a good sense of the state of development/stability/soundness for SSB. If you (or anyone) has experience actually using SS…

ftr we're moving Matrix to be more p2p in future (by letting you run servers clientside if you so desire), although this is a while away.

Re: ActivityPub: decentralized social networking protocol

#99

Post by adamnemecek »

hateful wrote: post #64

My only question is: Is this a Twitter or Facebook replacement? Because if it's only about someone status and you can't post something on someone's wall/timeline, then it will never truly complete with Facebook. It was the only thing missing from Google+ IMO.

It would be a federated network. You can think of it as email.

Re: ActivityPub: decentralized social networking protocol

#100

Post by JepZ »

SamWhited wrote: post #59
JepZ wrote: post #53

Earlier quoted context omitted.

Fair enough, 'complete' might be the wrong word here too (as you do not have to support all XEPs), but currently my biggest problem is, that Conversations (Android XMPP client) works pretty good (something I would consider 'complete' in terms of messaging), but I could not find any desktop client which works on a similar feature level. For example how many desktop clients support OMEMO, MAM and Carbon copies? Those a…

Desktop client support is lacking, but I think Dino (a relative newcomer) does a pretty good job of being compatible with Conversations and being "modern" (for some handwavey value of "modern") messenger based on XMPP: https://dino.im/

Last time I tried Dino was 4th August, but I can't remember what made me stick with Pidgin. But hey, if Sam Whited suggests Dino I will try it again :-D

I love the XMPP and Golang stuff you are doing.

And far as I can see it Dino seems to have pretty good XEP collection nowadays:

https://github.com/dino/dino/wiki/Supported-XEPs

Post reply on HN