Hacker News new | past | comments | ask | show | jobs | submit login

I've contribute to Mastodon and run an instance. Yes, it's very silly to think you can use Activity Pub for non-public things .. but isn't that going to be true of ANY distributed social networking protocol?

Direct point-to-point we can make secure (relatively) yes. You can run your own e-mail server, setup up PGP keys, and once you make it through that usability nightmare, you now have secure e-mail (if you trust your hosting provider) that will probably get dropped as SPAM 1/3 of the time when e-mailing anyone on Google/MS/Yahoo.

There's an interesting case where Mastodon and Pleroma respect and forward delete requests. Say you have a thread started on BigInstanceA and I reply from PersonalInstanceB. Someone from IAC replies to the same thread and B sees it, but A can't because C is banned from A. The reply gets dropped. You now have two conversations not in sync.

Say A deletes the original. B gets the delete request, but C never does, since it's a banned instance from A's perspective and doesn't exist ... even though it has a full copy of the deleted thread.

Deletes are truly fucking silly in the AP world. As much criticism as Zuckerberge gets (and deserves), back in the day he just wanted everything public, and I'm kinda for that too. If I post something online, it's never personal. If I need to talk about something personal, I call a friend, or text them, or meet them in a bar or plan my next vacation to be in their city. Real conversations don't happen in this space.




Not necessarily, if you use an actor-model where content is addressable using cryptographic keys, then you can get an object-capability system where having a reference to a piece of content is sufficient to grant access to it. This seems to be the way that some people are going with newer designs.

Also, the way you ban people is basically by having unique capabilities handed out to everyone. Then you can do various things to stop access (it's called a revoker in ocap jargon). See http://habitatchronicles.com/2017/05/what-are-capabilities/


Perhaps ActivityPub is struggling because it tries to be too much. If it does well at being Twitter, why must it also be Signal messenger? I don't use DM's much at Twitter, if that feature wasn't a part of AP/Mastodon, I wouldn't cry!

That comes across in delete requests. There's no way to guarantee that a server would honor that request. I don't think a blockchain style solution is needed -- just don't try to offer things that are impossible to offer. (There's this idea that AP/decentralized will be Nazi-free... what a ludicrous promise! Although, perhaps that's more an expectation of the users than the protocol authors...)


The protocol itself is aimed at being universal, so it's inherent to the protocol.


> Yes, it's very silly to think you can use Activity Pub for non-public things

What do you base your statement on? I've heard this take before, but I haven't seen anyone provide a good explanation for it.


I would guess it's based on the fact that when most people hear "access control" they think of "access control lists", but it's possible to do decentralized access control. That's what ocaps are.


I still don't really understand.

ActivityPub can be private in the same way email is private. All the people in the recipients chain will have a copy of the object you're sending. If in these recipients there's the Public namespace, then yes, you can't talk about "private" any more, but outside of that ActivityPub supports private interactions.

As a followup on this discussion, I actually spent half a day today to add private messaging to my ActivityPub service. It actually works.


Hi djsumdog! Weird to see you here!

Use search to find Kaniini's threads about Rapunzel.

Also, no, it's not something inherent in distributed social networking as a whole (previous attempts have avoided it), and it's not even inherent to push protocols, but without a bit of thinking behind it, it's easy to collide with.

Deleting is stupid, though, yeah.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: