Alex Chapman (moved to new account)OK, if anyone sees anything from this person: Ra (Freyja) (it/its)𒀭𒈹𒍠𒊩 (@[email protected]) regarding #ThriveMessenger he is just trying to find excuses to discredit me and my fellow devs work. He is just a guy that thinks that he knows it all and thinks that we should go overboard with our local dev environment, AKA our own computers that we are git pulling and doing the coding on, not just the server the application is hosted on. Like dude, no one goes out their way to do TLS shit on their home computers.
Like obviously we connect to websites with https, but we don't need to be running certbot and shit like that on our windows machines just because we're coding, fuck off with that shit!
tunmi13@alexchapman Just like "We don't need to hash our stuff either because it's an alpha build."
@tunmi13 OK that's irrelevant to what I was on about, this guy was going out his way to basically try and make out that no SSL on my personal computer, which is not hosting the application, is the worst thing ever. Like obviously when accessing websites its using https, but this person was acting like the fact I haven't gone out my way to fuck with certbot or whatever is used on Windows to do that shit, is the worst and bla bla bla. Not just me, but Stu and others that help out with st uff.
Brandon@alexchapman If it was really that easy to run native certbot and stuff on windows, I would be selfhosting Azuracast on my desktop. Fact is that is not a trivial thing to do without lag.
@serrebi Yeah exactly
@alexchapman Uh... This is most definitely wrong. Lmfao. Yes, people do TLS on their dev computers. It's called having a dev certificate. It's self-signed, yo ushould perhaps learn about what your talking about before you criticise it.
@draeand But I don't open ports like a lot of others do, and this freya person was acting like not doing that is the worst thing, like literally, if I had ports open then yeah, but when editing code locally and then git pushing its not needed.
@alexchapman So what? TLS is always something you should be testing locally. Especially if your using a protocol which makes TLS a requirement. I know at least one protocol that requires TLS as a part of the protocol, it isn't an optional thing you can turn off
@draeand Yeah, when you're running shit on a server, but if you're just running tests before pushing changes to the VPS and stuff then yeah, this guy was basically trying to discredit me all because my windows machine, which doesn't have ports open, doesn't host any shit that is supposed to be on a VPS or other machine, doesn't have the SSL shit set up. I'm not the only one that doesn't go that far, a lot of people don't bother, because its not a requirement to write code and run tests.
@alexchapman @draeand I don't have SSL on my dev server. I have SSL because it's hooked under a cloud flare tunnel, but I don't have SSL itself on my local computer
@adisonverlice @alexchapman Maybe not but if your developign something over QUIC for example you have no choice as to whether TLS is used or not.
@draeand @alexchapman I don't even think Alex knows what quick is lololol
@adisonverlice @draeand Quick is how fast something is lmfao
@alexchapman @adisonverlice It's QUIC not quick lol
@draeand @alexchapman yeah, he doesn't now what quic is, why does he need to worry about it?
@adisonverlice @alexchapman I didn't say he had to worry about QUIC, I was pointing out that it is at least one protocol that has mandatory TLS, and it wouldn't surprise me if there were many others
@draeand @adisonverlice Right, well that's why for something like that instead of messing around with certs on the local machine I'd just have a test version on the VPS but not to where anyone can log in and do shit.
@alexchapman @adisonverlice And as I said, that introduces an entire new set of issues. A dev cert literally takes 5 minutes to set up and it's a one-time thing
@draeand I think it's based on http/https and activitypub, nevermind its based on python
@adisonverlice @draeand The https and activitypub thing you're thinking of is Fedi+
@adisonverlice QUIC? If you mean that it's UDP based. Idk what the actual protocol for Thrive is
@draeand @adisonverlice Its not even a proper protocol, its literally whatever the fuck MSN/WLM used to do.
@alexchapman @adisonverlice And why are you mimicking what they do protocol wise? Why not just use your own and emulate their user-facing behavior?
@draeand @adisonverlice I wasn't the one who initially made the thing, Seedy did. And that's why once all the interface jank is sorted along with certain random disconnects and glitches that people have reported, then its gonna be a case of sort out a proper protocol.
@alexchapman Do you have any evidence that so many people just don't do that? Because I would say that's very specific on what it is your developing
@draeand Well I wouldn't be surprised, because doing that on Windows means messing with extra stuff instead of developing.
@alexchapman Uh no it doesn't? Have you ever heard of the openssl command line tool? Using self-signed certs, even system-wide, is not a non-trivial thing to do on pretty much any operating system
@alexchapman Also, development velocity is not a metric yo ushould use to judge how well your doing, because the metric is so vaguely defined as to be useless to begin with.
@draeand Yeah well I've never known anyone to do that shit on their own machines, they just crack on and if something needs testing with SSL they set it up on their VPS and if they're not ready to push it out to the main application they set up a test version on a subdomain and have it as a fresh instance, database and all, that way only the dev, or devs, can get on to that version.
@alexchapman Aaaaaand that's how you get "well I accidentally found this test version which shouldn't have been exposed but was by accident" security vulnerabilities. TLS testing is good to simulate a production environment *without* going into full production. And generating the TLS cert can literally be done in power shell, something like this will do it just fine:
$cert = New-SelfSignedCertificate -DnsName "localhost" -CertStoreLocation "Cert:\LocalMachine\My"
Seriously. Or the openssl CLI can do it. Please actually in future read about the things people complain to you about before going and acting like you fully understand the landscape. As it currently stands, your making a bunch of confused statements which are logically incoherent. TLS for one doesn't require that you open ports. Ports have absolutely nothing to do with TLS whatsoever, in fact.
$cert = New-SelfSignedCertificate -DnsName "localhost" -CertStoreLocation "Cert:\LocalMachine\My"
Seriously. Or the openssl CLI can do it. Please actually in future read about the things people complain to you about before going and acting like you fully understand the landscape. As it currently stands, your making a bunch of confused statements which are logically incoherent. TLS for one doesn't require that you open ports. Ports have absolutely nothing to do with TLS whatsoever, in fact.
@draeand Well, the security issue (Passwords in plaintext) got fixed days ago. This was set up to be a modern take on MSN/WLM, and things like XMPP or Signal protocol, or whatever E2EE we choose to use is coming once all the UI jank and any server side oddities get ironed out, which is gonna be in the next couple of days. So most likely that stuff is gonna be looked into next week.
@alexchapman Also, "lots of people don't bother" is an appeal to mediocrity and isn't the flex you think it is. Lots of people don't write tests, too. So by your own logic, we shouldn't test our software
@draeand No, I was just stating from what I've seen, not logic
@alexchapman Okay, so then what is your threat model? What do you think E2EE is? Because security should never be something you just bolt on after the fact. That will leave your messenger a scandle behind, all the time, and your users will be the threat model. And you really, really don't want yoru users to be the threat model, because most users do not appreciate being used as guinea pigs. Consider that users will (not may, will) transmit sensitive information via your app, because they reasonably believe, based on yoru statements, that security is really something you care about. You telling me "we'll figure it out later" is you hand-waving away genuinely hard problems, and tells me that security is something you don't really care all that much about, because security needs to be baked in from the start, not something you do as some kind of afterthought.
@alexchapman I would be happy helping you out with this stuff (as, I'm sure, would many many others), but the last thing you want to do is go delaying critical features like this. Security is something that will make or break your app. If you don't take it seriously from the very beginning, your app is going to be DOA.
@draeand I've heard of things being quote unquote, DOA, then time goes by, problems get fixed, and then boom, it blows back up in popularity. But I get it, and that's why E2EE is gonna be sorted soon, but before we go doing that, there's still some weird bugs people are having where the client randomly disconnects, or sometimes it'll fail to send a message, or whatever, I've got the messages and replies people have been sending in, so there's that.
@draeand E2EE is messages being encrypted at both ends. But its getting done, which is better than never. As for security, that's not just bolted on, as the plaintext issue was fixed as soon as it was brought up, but E2EE requires going from the current way of doing things to using an actual protocol, rather than just pulling an MSN/WLM and having messages sent from the sender to the recipient without any kind of stuff going on behind the scenes. Oh yeah and that plaintext problem wasn't intentionally left there, me and Seedy originally started this thing last year, then development stalled a lot and it wasn't til the Discord drama when Seedy decided to pick back up on development, and then it got mentioned a couple of times and suddenly, a whole bunch of people signed up in the space of a couple of days, and we then had to get stuff sorted, bugs fixed and then yeah.
@alexchapman I think you are confused. E2EE Edoes not require a protocol on top of the one you already have. E2EE is also not exactly the definition you noted because it is way, way more complicated than that. You have a protocol. Add E2EE into it. Don't try to hack XMPP into your protocol. Before you go even considering E2EE, you need to understand it. Part of that means asking questions like: Is E2EE planned for 1:1 only or also groups? Will each device have its own keys? How do you handle device add/remove? Do you want forward secrecy and post-compromise security, or just static key encryption? How will clients authenticate who they’re talking to? What's yoru server threat model? The signal protocol is so complicated (with it's double ratchet, X3DH, etc.) because E2EE is in fact insanely difficult. And group-based E2EE is practically an exponential problem, and the only protocol I know of that solves that is MLS. Which is yet another layer of complexity.
@draeand Well, either way, I wanna do it in a way where people don't have to have some 60 character recovery key shit going on, just where they use their account password or passkey to access things. And some people were wanting federation, so some changes to how things are done would need to be made anyway. Once all the current bugs are fixed that have been reported then stuff like that can be tested and implemented. I am gonna definitely do more research into the protocols and E2EE methods.