[agmcleod]

Ah i think i may have misunderstood how the system is made. It is purely peer to peer. So any issues could be if the software has a security vulnerability, but I'm not sure how that ties in with things like "as-use" open source licensing. This post explained the network fairly well I found: https://staltz.com/an-off-grid-social-network.html

As far as GDPR goes, you're right because you're specifically choosing people to send it to. However, having a mechanism to delete your messages on other people's systems when they sync would probably go a long way.

[aeorgnoieang]

Are you claiming that GDPR holds individuals liable to delete info they might have about another person on request?

[icebraining]

Only if they are using that data in a professional or commercial activity.

[kyledrake]

> having a mechanism to delete your messages on other people's systems when they sync would probably go a long way.

It is my understanding at the moment that it's not scientifically possible to do this. If I'm mistaken I would love to hear a proposal for doing this, but I don't understand how full read access can be revokable once you have the data and a way to decrypt it. DRM doesn't count/work.

[ytjohn]

Not technically possible currently (well, last I checked). A client could be configured to send a "please delete message id 29342" type post, but other clients would have to know how to understand that and to honor it. The functionality would be similar to "sender has recalled this message" in exchange.

Also, the way the protocol works is that clients discover the most recent log entry number, and then request all "missing" ones. So that delete message would be more like a "please overwrite message id 29342 with zeros or something".

[strypey]

Is it possible to do revocable private messages in a decentralized system. My understanding it that the Zot protocol (used by Hubzilla) deals with this by keeping private data on the hub of the user sharing it, while public message can be mirrored to the hubs of any users receiving it. "Sending" a private message (or media file) to another user actually sends a notification to that user that they have permission to access it. When the receiver wants to access the message, their hub has to correctly identify them to the sender's hub, using credentials sent as part of that notification. But all of that is handled in the background, not a painful, confusing manual process users have to know about. See: https://github.com/friendica/friendica/issues/2894#issuecomm...

From what I understand of SSB,it works by distributing messages to receiving users as part of a blockchain, making all messages effectively public, even if not published with the goal of giving the public access. But maybe similar functionality could be added by setting up private "clubs" - pub servers set up by groups of users who know and trust each other - which would play the same role as a Hubzilla hub, storing private messages and displaying them to users who can authenticate correctly.