It seems like a lot of Mastodon requests/expectations are based on a flawed understanding of federation and the idea that a post exists as a shared object in a common database, so you can apply other states to it after publication.
It is not like that at all.
Federation is like email, right, and you can send email to different servers? Well, posts are like emails then. Or faxes. You aren't sharing the same object, you're sending a copy. You can't decide to "make it private" after it's sent.
@frankiesaxx I've seen similar conversations with folks in Matrix too.
Mastodon made me realize that the protocol mindset I got implanted via #IETF and others is definitely not a shared understanding of reality.
Going to write a book about it.
@frankiesaxx Generally I am a fan of the idea that there per se is no "private" data as soon as I decided to leave a copy of it on some computer not under my control, centralized or not.
@z428
Same. I use "private" channels for online communication as a courtesy like I use headphones on public transit.
I think of it as noise reduction.
@frankiesaxx Curious how the "delete and re-draft" function works in this context.
@frankiesaxx Good point! But, if i understand well how Mastodon works, the email is only partly functional as an analogy, as, when you decide to delete your post, it is deleted everywhere. And, again if i'm not wrong, this behavior is difficult to reproduce with an email metaphor...
If one of you knows a clear explanation on how mastodon federation works (or how ActivityPub works), i'm interested. A growing audience is probably legitimately eager to understand it without learn how to admin it.
@crickxson
That "delete" happens because your server sending a request to other servers with a copy asking them to l delete their copy as well, the same way when you use software that supports remote email recalls.
Between Mastodon servers this interaction creates an illusion of deletion, but it doesn't mean the post no longer exists. Some fediverse software doesn't have this functionality. (Which is why delete/redraft is super annoying to ppl on those servers :)
@frankiesaxx Wow, i discover the remote email recalls feature! Thx! So yes, emails with this function are a good analogy (faxes probably not unless using an auto-burning feature!) - There is this good introduction https://kevq.uk/how-does-mastodon-work/ by @kev - But does anyone know more detailed ones? Or even a list of resources? If not, we can create one.
@frankiesaxx
The delete function is part of the specs. It's not our fault those ppl's instances have an incomplete implementation
@crickxson
@frankiesaxx @crickxson
Which makes me wonder, shouldn't instances "announce" themselves by providing a list of implemented features so that other instances can make an informed decision on whether to federate or not?
@frankiesaxx @crickxson
Also, shouldn't Mastodon be able to change the visibility of posts by sending a post-facto delete request to other instances? (But some restrictions would be needed to prevent abuse)
@rick_777
Yeah possibly, but I sometimes wonder if maybe it's really the best possible choice to try and put a cosmetic interface over hacks trying to emulate the strength of a centralized platform.
I know that's the only frame most people have, but maybe there are ideas that would play to the unique strengths of federation?
@frankiesaxx
But changing a visibility from public to unlisted would be a new feature. You delete a post but only on other instances. That would indeed be a new application of federation; and I think it would be useful.
How about adding a two or three minute timeout for federation, so if the user says "whoops I shouldn't have made that public", they have the choice to change the post's visibility? Like gmail's "undo send" feature.
@rick_777 something like that could also be used for a proper editing window, rather than a delete-redraft kludge @crickxson
@rick_777
That would be useful in a number of ways. Not necessarily just binary federation on/off but it could pop a notice to users "this server cannot delete posts; do you still want to send?" type stuff.
Of course deliberate bad actors could lie, like Mastodon apparently does with some error codes.
@frankiesaxx
Yes, of course. That doesn't mean we shouldn't try to improve how good actors are supposed to behave, tho.
@crickxson
@rick_777
I suspect there will always be non-compliant software out there though ;)
What's your novel about?
@rick_777 @frankiesaxx @crickxson some of the apps haven't finished their implementations of #ActivityPub yet, and are still federating with Mastodon via #OStatus. I'm hopeful most of them will roll it out by the end of the year (or at the lastest mid-2019). In the meantime, the behaviour of the meta-federation of all the apps remains *very* complicated to explain to newbies ;) Email was probably the same in its first few years (#FidoNet between #BBS prior to the net etc)
@frankiesaxx, you can’t tell me what I can’t do to your copy! /s
@iiogama
*breaks into your house and deletes shit off your server*
@frankiesaxx That is a helpful metaphor. Thank you.
@frankiesaxx An even simpler rule for the non-techies, "What you post online is forever."
@WTFFlorida
Yes but people are conditioned to believe the illusion.
Like I've seen total meltdowns when an emergency restore brought back some "deleted" posts in forums.
@frankiesaxx Isn't it more like Usenet? Not that that would help people who don't know what Usenet is, but it would at least explain such things as deletion of items - which is as I understand it just like Usenet if Usenet servers were usually set up to honour article cancellations.
@mattskala
Haha... yeah I was thinking about that as I wrote it but I am not gonna try and use Usenet as an analogy to explain federation I feel like that's a rabbit hole would not clarify *anything* XD
> You aren't sharing the same object, you're sending a copy. You can't decide to "make it private" after it's sent.
What if you could make it the SAME object and not just a copy? With encryption, you can send an encrypted copy and the decryption key would only be stored in a temporary cache AND in the originating server as part of the post. If the user deletes his account or the post, the decryption key is deleted and the post is no longer readable.
@rick_777 that's an interesting idea. Presumably this requires a unique key for every post. How would this affect server resources and scalability do you think?
@frankiesaxx
A one or two day cache would take care of scalability, and servers would be able to ask for the keys for messages after they're requested again - which wouldn't be so often given the ephemeral nature of microblogging (people always want the latest data).
@rick_777 What about the act of encrypting/decrypting itself? (It would be negligible for a single user obvs, but I'm thinking on a mass scale, like say the Mastodon.social timelines?)
@rick_777 (I'm not trying to shoot your idea down! I think it's a really neat idea :)
@frankiesaxx
Your theoretical objections are both understandable and necessary. Having a devil's advocate is required for new ideas to test their feasibility.
To answer, I could simply say that
people had the same objections regarding SSL. Using standard algorithms that can be optimized (e.g. AES) is recommended; then we can either classify encryption as either negligible or necessary for the sake of privacy.
Once the infrastructure is set, we can add new ftrs.
@rick_777 So the encryption would depend on the initial publicity level of the post?
@frankiesaxx
> So the encryption would depend on the initial publicity level of the post?
I don't quite get you, mind rephrasing?
@rick_777 I mean -- is the idea the encryption would be attached to certain publicity levels, so you could have the ability to revoke posts that are intended for some eyes only, while posts that are intended for public distribution are distributed without?
@frankiesaxx Yeah, that could work. I was still undecided of which case would go where, but I think your idea is the right one.
@rick_777 I was sort of thinking about this last night, and I think maybe looking at the kinds of objects we put out more in terms of Creative Commons licenses than the standard corporate copyright model is maybe more helpful in deciding how they should be handled, what reasonable expectations there are in control, and what the the balance of rights is. It's not a pure creator/audience relationships. There's also a strong argument for conversation as a collaboration.
@frankiesaxx
Such features can include self-destructing posts, enhanced privacy protection, restricting followers' allowed history viewing, and so on.
@rick_777 I do reflect on why there's so much emphasis on content control though. I can't help feel like maybe this is like a subconscious embrasure of copyright culture. I mean, you're basically talking about adding DRM aren't you?
@frankiesaxx
I hadn't made the connection until now, but I think you're right in a way.
Let's say that federation is forcing us to adapt the same restrictive measures that companies have on copyrighted works; after all, a user should be in control of his own words online. We didn't need these measures in a centralized server because all encryption was transparent; but in a federated architecture, we need to federate those restrictions and make them explicit.
@rick_777 I think the axiom "a user should be in control of his own words online" maybe needs to be unpacked.
This is where I feel like copyright culture is coming into it. We focus exclusively on rights of the author/user, but the reader/user has legitimate rights also.
Real world example:
You publish a pamphlet.
You change your mind about something you wrote.
Now you can stop publishing new copies, but you're not entitled to demand back all the copies already circulated.
@frankiesaxx
I see. I think it has more to do with the expectation of privacy online. The internet in general isn't privacy-friendly, but why shouldn't it?
Also, DRM is related to the disparity regarding of ownership. Corps believe they own their works, while also owning the public's data. The public believes copyrighted works belong to the public while user data belongs to the user - 1/2
So far, the idea that users should retain ownership of their online comments is a novelty; hence, the idea that your comments should be encrypted is a novelty, too. Corporations usually don't give AF about privacy, so things like the Equifax leaks happen. IMO, encrypting personal comments is a way of giving power back to the people. - 2/2
*note: I have to go offline now but I'll catch up on what you say tomorrow. Please feel free to write as much as you want on the topic though :)