Gregory's Server@renchap @Claire What if instead of sending the raw actor id in a delete activity you send SHA256(actor id)? The deleted actor id would never be broadcast in the open, mitigating the privacy concern. Instance2 receiving a delete from Instance1 would SHA all its local Instance1 actor ids and if one of them matches, that's the one to delete.
|
3 comments
@renchap @Claire It's pointed out as a "minor" privacy concern that servers who've never seen the account before the delete now know about its previous existence. This fixes that. I don't know how you get around having to broadcast to every instance you know. That's kind of the way fedi is shaped. You can make it cheaper to do a lot of deletes (batch 'n' bloom, as i lay out in my other post), but a single delete is always gonna cost you a trip 'round the verse. @renchap @Claire I think good use of bloom filters would be when you want to batch those deletes. Now instead of sending a single SHA to delete, you put all the SHAs in an appropriately sized bloom filter and send that. 1000 deletes with a 1-in-a-trillion false positive rate is a 7KB filter. Instance2 receiving such a bloom filter delete from Instance1 would SHA all its local Instance1 actor ids and check them against the filter. If it gets a match it does the delete. |
@JasonPunyon @Claire I am not sure how this would solve the issue of needing to broadcast it to every known server? There is not really a privacy problem here, as you reference a no-longer-existing account