Live data from Hacker News

ActivityPub: decentralized social networking protocol

w3.org

111–120 of 140 posts

Re: ActivityPub: decentralized social networking protocol

#111
post #51

Earlier quoted context omitted.

> which meant some clients may not honor the private status of theses posts. Does this mean they may have accidentally published a message intended as private, to the public? If so, I don’t think I can imagine a more efficient way to rob me of any confidence I ever had in Mastodon…

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.

Social media platforms are used for one-to-one communications and should support that. Furthermore, social media platforms should support sharing something with a group and only that group of people.

Really, the only time I should expect the content I share on a social media platform to be public is if I shared it as public content.

[Note that I am talking about technical capabilities and privacy here. Of course somebody with whom I shared private information can re-post it publicly, but solving that is out of scope for a technical solution - and is also true outside of social media platforms]

Re: ActivityPub: decentralized social networking protocol

#112

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.

i would consider a privacy-first approach a best-practice :)

Re: ActivityPub: decentralized social networking protocol

#113
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 disagree with that, though you might want to think strongly on what you mean by "privacy". For some people, this is strictly limited to the technical capability to prevent (or allow) the flow of information. I'd long subscribed to this point of view, but have found it inadequate, if only because capabilities have been changing so dramatically on this point. Rather, and this is something of a personal definition, th…

Your definition is not unusual at all, in fact, it is pretty close to the German definition of "Datenschutz" (data protection): Individuals have the right to know who has what information about them and the right to determine to what extent what information may be shared.

Re: ActivityPub: decentralized social networking protocol

#114
post #46
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…

should also take a look at https://datproject.org

very interesting and maybe better than SSB..

it has hypercore - raw distributed streams, and hyperdrive - file abstraction on top, and a whole bunch of related projects, like Beaker browser.

https://github.com/datproject/awesome-dat

the protocol could be turned into a generic federated messaging framework..

Re: ActivityPub: decentralized social networking protocol

#115
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…

> 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). There is a way to do this! Check out https://bockstack.org . We are working on decentralized identity and key management.

correction.. you probably meant https://blockstack.org

:)

Re: ActivityPub: decentralized social networking protocol

#116
post #114
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…

should also take a look at https://datproject.org very interesting and maybe better than SSB.. it has hypercore - raw distributed streams, and hyperdrive - file abstraction on top, and a whole bunch of related projects, like Beaker browser. https://github.com/datproject/awesome-dat the protocol could be turned into a generic federated messaging framework..

FWIW I'm 80% convinced that dat is the future of SSB. It has the technological foundations to do everything SSB needs and more. There is however one huge difference in philosophy, that can be solved with technology but still needs to be done: SSB gossips content through the human network and public places, while dat needs direct connectivity between peers. The former is better exactly for the reason that was mentioned earlier: Peers need to have some re-hosting if they want to have their content disseminated while they're offline, so the discussion can still happen. Dat will need to have the equivalent of SSB's pubs (no-registration, no-config, just connect and send).

There is a discussion about that somewhere but I can't find it anymore

Re: ActivityPub: decentralized social networking protocol

#117
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…

The scuttlebot link mentions append-only. Does this include the possibility of appending a "delete" or "edit" message?

Yes, exactly: https://github.com/dominictarr/ssb-docs#is-it-possible-to-de...

Re: ActivityPub: decentralized social networking protocol

#118
post #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-sign…

I know what the signatures are for but I wonder if there's a simpler way to achieve these objectives.

Server authentication: For example XMPP uses client certificates to authenticate servers to other servers (TLS server certificates usually can be used for client authentication too).

Message authentication: maybe exchanging OpenPGP messages would be easier? They already are signed and the payload can be anything. Of course it's not as easy to list a collection of these messages as it is with JSON (just collect into an array).

> If you avoid LD-signatures then you don't have to mess with JSON-LD canonicalization either,

I want to be interoperable with existing software so avoiding it is not a practical option (although allowed by the ActivityPub spec). Just like having non encrypted HTTP2 is not a practical option (although allowed in the spec).

Re: ActivityPub: decentralized social networking protocol

#119
post #11

Earlier quoted context omitted.

As a counter example, there are millions of non-technical users using the bittorrent protocol. They are running a server on their machines and not aware of the technical complexity that lies underneath. I am not saying it's an easy UX problem to solve, but it can be done.

BitTorrent only works well (i.e in a true peer to peer fashion) if many people are serving up the same files so that some sources are always online. Outside of piracy that is rarely the case.

People will serve whatever the software wants; serving only want the user explicitly selected is just an option.

For example, in Freenode you don't control what gets downloaded and served (which also helps to hide what you're fetching on purpose).

Re: ActivityPub: decentralized social networking protocol

#120
post #26

Misread as 'Decentralized Pub', am sad I was wrong. (although, that now just sounds like 'drinking alone')

You should check out Scuttlebutt

https://staltz.com/an-off-grid-social-network.html

https://www.scuttlebutt.nz/getting-started.html

https://scuttlebot.io/docs/basics/install-the-database.html

Post reply on HN