kai (they) 🛠I was thinking about a content auto expire feature for mastodon, and I would love people's feedback https://github.com/tootsuite/mastodon/issues/1295
some other issues I made today...
Allowing admins to extend the Getting Started menu https://github.com/tootsuite/mastodon/issues/1298
Adding a timed silence option for admins on reports https://github.com/tootsuite/mastodon/issues/1284
...it occurs to me that most of my issues are gonna be admin issues, so not relevant to most ppl
iris@cyrinsong I would really appreciate this feature, honestly.
Spider@cyrinsong interesting.
Self destructing filesystem?
@Spider more or less
@cyrinsong
I've always been fond of the idea of storing my users files on a drive that randomly purges a few files that haven't been touched in 2-3 years.
I've always been fond of the idea of storing my users files on a drive that randomly purges a few files that haven't been touched in 2-3 years.
Darius: Moving Accts, See Bio@cyrinsong this makes me want a plugin system for Mastodon so people could publish third party plugins and instance maintainers could choose to implement them or not
@tinysubversions yea, something like adding mastodon-autoexpire to your gemfile for your instance
(or however that would be implemented)
@tinysubversions although there's quite a lot of thoughts about design and architecture that go into whether something should be an options flag versus a plugin
@cyrinsong yeah, definitely. I tend to the "everything should be a plugin" side but I understand the arguments for the other side of things too, and I don't feel terribly strongly about it
the grugq@cyrinsong I'm for it.
tduehr@cyrinsong One way to think of Mastodon is as email with a 500 char limit and default bcc all. Recalling an email—where supported—is just sending a second email saying you want to recall the previous email. Without client cooperation, that doesn't work. You might be able to do it in the official client but anyone that's ever received it can push the message out again in some form or another.
@tduehr I get you. Can you say as much on the issue itself? I'm not totally familiar with how deletion interacts with federation
@cyrinsong Its not a problem due to federation. It's due to the nature of digital communication. To talk to someone else, you have to give them a copy of the message. It's their choice what happens with that message once they get it. The best you can hope for is official clients using DRM like protections against the local user. That didn't work for Snapchat. It really just can't work unless you can figure out some kind of temporal encryption.
Doc Edward Morbius ❌@tduehr @cyrinsong Suppose there's some key / repudiation mechanism involved. Messages are published, but encrypted, with a matching key. If that's revoked or destroyed, the message is no longer available.
Alternatively, instances which don't respect (reasonable) delete requests are blocked, for a time, permanently, whatever. They might still be able to obtain messages, but they'll have to work increasingly hard for it.
Building trust, reputation, & compliance is hard.
@cyrinsong @tduehr I'm not sure my first suggestion even makes sense, but I've been kicking around variations on that for a while. It's a place where blockchain might actually solve a problem, or some other time-based chained-key mechanism.
@dredmorbius @cyrinsong It's not just the instances that you'd have to worry about, the clients must conform as well. Block chain doesn't do anything for you here. There's no way to prove deletion, let alone deletion of all copies. Until someone figures out some sort of temporally keyed encryption, this just isn't doable.
@cyrinsong sorry. You meant the GitHub issue.
Interlocutor@cyrinsong Brilliant. +1