With “guarantees” I meant things like whether you want to have perfect forward secrecy, or whether you want to provide some degree of deniability, and so on, not so much what kinds of guarantees you’re relying on although they’re definitely also good to keep in mind.

“As secure as possible” is a very all-encompassing goal which doesn’t really say much – what I was trying to get at with my point about the guarantees you want to make is that you’ll want to have a clear idea of what you actually mean with “as secure as possible” so you’ll know what sort of eg. architectural decisions to make before you do a lot of work and paint yourself into a corner.

It’s a very ambitious project, but I can guarantee it’ll probably be very interesting to work on and you’ll learn a lot regardless of the outcome, and I’m definitely rooting for you.

I have a background in distributed systems and some background in security (I’m by no means a cryptography expert but I do know more about the subject than average developers), and I’d say that at this stage you shouldn’t worry too much about meeting all parts of some guideline or another; they’re often geared more towards bigger teams and slightly more established projects. What I think could benefit you would be first of all to have a clear idea of what exactly you want to accomplish (from a security standpoint, not necessarily so much from a functionality standpoint) if you don’t already have have one, ie. what sort of guarantees do you want to be able to make. Doesn’t have to even be a public document at first, just some notes and sketches for yourself. Then you’d want to find other projects with similar guarantees and aims and see how they did things, find research papers on the subjects and so on. Security guidelines can be useful, but generally it’s more useful to understand why something is in a guideline in the first place. For a project such as yourst I would personally really emphasize design documents and research over code at an early stage, because you need to have a clear goal in mind before you start cranking out code which might turn out to be worthless (at least to some degree) after you run into problems with your approach. Not saying that the documentation has to be public, just that you / the team know exactly what the goal is.

“Encrypted P2P chat” can mean vastly different kinds of projects, with very different aims. For example, do you want perfect forward secrecy? If so, you’d want to find out the challenges associated with it, especially in relation to interactivity since you’re building a P2P architecture, etc. etc. Same with anonymity / user “traceability” like I mentioned earlier; you need to have a clear picture of what kinds of guarantees do you want the users to have to be even able to say what kinds of best practices you’d have to follow.

Sorry, that turned into a bit of a ramble and might be completely obvious to you already, since I have no idea about your background and the level of research you’ve already done.

Right that makes sense.

But yeah, after glancing through the links you provided, I’d agree that you’ll definitely need to pay someone for an audit / review, there are so many pitfalls and gotchas when it comes to encryption alone, and depending on the guarantees you want to be able to make you’ll find even more pitfalls and gotchas – especially if you want to make even relatively light guarantees about anonymity. The classic problem is that even with encrypted payloads the metadata / protocol itself leaks information, which might or might not be a problem depending on what your guarantees are.

I’d suggest writing at least some level of documentation for the protocol. I’d assume a lot of the more security-minded folks – who your app seems to be targeting – won’t be too enthusiastic about using a chat service that promises security but doesn’t tell you how it plans on achieving it.

Is there a description of the protocol somewhere?

Probably the majority

The big problem is rather that a lot of innovation has been absorbed by the big companies via buyouts

Which ultimately does seem to lead to innovation slowing down. The big players buy out any potential smaller competitors, and very often just outright kill the products / services they inherited in the acquisition.

It feels like actual innovation in all sectors has slowed to a crawl, and corporations – especially the ones run by MBA parasites – are concentrating more and more on just squeezing money out of people with various bullshit tactics, while at the same time thinning their workforce (naturally the MBAs are never under threat, though)

Microsoft security practices haven’t changed much over the decades

But why can a theme make web requests?!

Because we live in a broken world and nothing matters.

On a more serious note, it’s a pretty horrifying misfeature. What’s even more worrying is that by all appearances Microsoft doesn’t give a shit, if they apparently didn’t even bother removing the malicious extensions that were reported. Not that I’m surprised, but still.

I’ve found Codeium pretty handy, especially for boilerplate-y stuff like unit tests, and it can very often “guess” what I’m going after especially if I eg have a TODO comment or something similar where I start completion. Doesn’t always work but doesn’t get in my way either, so overall it’s been a benefit

edit: note that the language you write will likely be a factor. When I tried Codeium with Julia, the results were often pretty meh likely because it’s a more niche language, but with eg Swift it’s been fine

That’ll happen with every language, there’s always more to learn.

Whatever is the opposite of imposter syndrome, I think you have it.

Dunning-Kruger effect?

Yeah I really don’t know where hostility against newbies (actual or perceived) comes from in nerd circles. It’s been like this for as long as I can remember, and I’ve been eg. using Linux from the late 90’s and fucking around on the Internet for over 30 years now. At least things are way better than they used to be, but it’s still sometimes a bit of a bumpy ride

I’ve run into this problem with many open source projects. It’s sometimes really hard to find out what the hell something actually does based on just the project’s own pages. It took a while for eg. join-lemmy.org to actually describe what Lemmy is, for example, instead of just going on about it being open source and secure and federated and blah.

They already said he is a manager, no need to repeat

Pretty sure I’ve seen that one on IRC in the 90’s

Platypodes

April 2024: God dies of terminal cringing

Well, it’s not like they said they gave it their best, and I really doubt they did.

They might have had a couple of trained monkeys bashing typewriters for 3 years in a room with the sign “Apple Watch for Android team” on the door for all we know. They just said they were “working on it” before scrapping the idea