• he/him

guy who was too into deus ex


Anschel
@Anschel

Decentralized servers and custom clients would solve a lot of my problems with that app, but too many of The People I Want To Talk To use it


ireneista
@ireneista

1. message IDs

this is a requirement for a lot of the small features that cloud-based corporate chat apps have, that users have come to expect. reaction emoji, tagged replies, message edits and deletes...

some of those features are fundamental changes to assumptions about the IRC message history being a log of what has happened, not something that a central actor doing policy enforcement could do after the fact. this is important because if it is POSSIBLE to apply central control, the legal system will force it to happen.

there are also technical challenges here, but they're solvable, there are fairly well-known techniques for generating identifiers in a distributed fashion, it's not that it's easy but it's doable. however, the EASY way to do it would be to move to server-side state, which is the other big issue.........

2. server-side message history

hopefully everyone involved in actually running IRC understands why this would be bad. for example, the persecution of marginalized communities is harder when chat logs live only on end user systems and not in a single central place whose operators can be threatened, subpoenaed, arrested etc.

so since - as far as we can tell from a great distance - server-side history is rightly off the table, the challenge is how to convey to users that you can only see messages that happen while you're signed in, when everyone today has forgotten what it even means to be signed in due to the prevalence of cloud architecture. once people understand what it means, you also have to convince them that it's a good thing, but first you have to get them over the learning curve at all. today, in our personal experience, most new users trying IRC are confused by that and don't understand what's happening, so they bounce off it because it feels unusable. no, recommending irccloud does not solve the problem.

so, what do?

well, hopefully if more people understand this stuff we can all talk more about how to handle it, and eventually get to an IRCv3 spec that isn't deadlocked on fundamental questions, and then get it deployed and get the masses on board

we want to be clear, the fact that IRCv3 hasn't been rammed through despite these questions is a good thing, a sign of a healthy process driven by genuine concern for the safety of users

also we hear about all these discussions second-hand, we don't participate in them directly, so if we're misunderstanding or misstating something, we apologize. we are bringing our own privacy experience and anarchist organizing theory into this, as well, so there's a fair chance that we are seeing something as being "really about" an aspect of it that others wouldn't perceive as fundamental, but we tried our best to report it how we see it.

anyway! since these are political questions, not technical ones, the solution to them is public awareness and public discussion. if you read this far, you're already helping. thank you!


Anschel
@Anschel

These are (unsurprisingly) good points. I guess it brings us back to the Real Problem being that it has become super niche for a Normal User to have a small server at home, even though that's a thing that totally could be in reach financially. It's just unexpected so the support isn't there.


You must log in to comment.

in reply to @Anschel's post:

in reply to @ireneista's post:

I can see how not having centralized history is a fundamentally good thing, but at the same time not having message history available from while I’m offline makes a service immediately unfit-for-purpose for me.

Although that’s also a design question I imagine, just thinking for a few minutes while composing that reply I’m imagining all sorts of nice cryptographic solutions to “make sure all these messages are eventually delivered to the participants” even without any centralized state. But it’s just another case of the people trying to do things right having to work in hard mode.

right, like, Matrix does this with centralized state, but with encryption so only participants are supposed to be able to read it. we still don't feel sure whether that's good enough, it's a hard question.

as you say, it sucks that the "wrong" ways are easier :(

I don't recall whether DCC (direct client-to-client) protocol is actually part of the IRC specification, but I never saw a client without it; and in any case most of this solution could still be client-optional.

in the IRC3 protocol, assign each message a UUID, scoped to channel; that should be a small enough hash space. might as well also timestamp them, so they can be disambiguated even with collissions. (I'd trust timestamp alone less than UUID alone, due to traffic burst vulnerability.)

you have now enabled both peer-to-peer disambiguated history sharing by way of opt-in DCC exchanges, and replies/reacts. (replies should go in the core protocol too, just to avoid splintered standards when clients roll their own. reacts are a smaller concern, since with replies specified it's obvious to piggyback them.)

there are privacy tradeoffs here (timestamps make useful join keys...) but we do think something along those general lines is a good idea

the trick we have seen before is that an ID is a tuple (server ID, timestamp, serial number)

of course, we saw this in a context where 64-bit collisions would happen in practice (it's more likely than it sounds, due to the birthday paradox). it's likely that a chat server wouldn't be so high-traffic as to run into that. still, there's going to be at most a hundred servers or whatever per network, likely less than that, so it isn't going to be the difficult part for whatever index structure is used.

Ah, the good old days of being "AFK" and people coming up with goofy ways to work "afk" or the like into their name to indicate it. For those of us who've had the linux box at home up and online all the time since we first replaced dialup with broadband keeping our own history when afk seemed natural but I guess that's not just natural to everyone anymore!

in reply to @Anschel's post: