Sorry, to clarify, when i say protocol I specifically mean the E2E encryption protocol.
Also, have you thought about asking your clients/whatever to use one app to communicate with you? Even if you get half of them onboard, it sounds like it would save you a lot of mental bother.
My intent wasn't to diminish your initial comment, just that a protocol is a technical answer to a problem that is more probably a societal one. It takes time and effort to commit to another communication protocol, especially when it's not the core of what you're doing as a project. Maybe what is needed is not just a protocol but proper tools to make it easy to use (and the bar with the simplicity of email is very high)
I'm nobody. The point of a protocol is for others to use it. Also,there are 'ok' alternatives for messaging like signal and wire. But yeah,i don't want to spend all my time working on something no one will use :-)
As someone who has been working on this for a very long, my advice is to write the software to be protocol agnostic. Be able to switch out protocols easily, and support multiple protocols concurrently, because we still have no idea which protocol will win out. It may be something that hasn't even been built yet.
innovation and differentiation are not things i need or want in my messaging app, holy cow, i just want to send messages. use a standard protocol or write a new one, i don't care, but the problem you are solving is SENDING MESSAGES TO A KNOWN USER. write a protocol, document it, and let the client handle the rest. omg. grow up
As far as I can tell, that's exactly what TFA proposes (while also trying to be user-friendly).
> You don't need completely new protocol for that.
You need a protocol because protocols can be audited and built upon. User-interaction protocols are very much a part of crypto and, IMHO, trying to minimize the user-error surface is critical for cryptography's development.
This is about bringing crypto to the average Joe. You think they're going to download several heterogeneous tools, learn to use them, devise their own security protocol... and also not mess anywhere in the process? I don't think so!
If a protocol+app saves them the hassle and lowers the chance of mistakes, why not?
Also, as they point in the article:
> One could simply throw out the last 30 years of protocols like SMTP, IMAP and PGP and reinvent the wheel like DarkMail, but we at Whiteout believe in building on existing standards, since they aren't going away any time soon.
Alright, but that is just theory. The reason you'd want a text protocol is so that humans could read it. Once you secure the protocol, you can't read it without a machine to help you.
If they were using the protocol, they have two options:
1. Roll their own implementation (highly discouraged). Increase their development burden. Introduce higher maintenance burden. Slightly more flexibility for app deployment. And run the risk of my company disallowing interoperable embedded commercial implementations out of security concerns for the users. Basically, at this point the company is better off not using the protocol.
2. Use our implementation (Hypergolix). Massively decrease development and maintenance burden. They now have an install dependency, though, so distribution is a bit more complicated. Significant reduction in time and money invested in the app.
The critical point is this: with option 1, you're correct in that you don't know the protocol is in use, but it's extremely likely that they wouldn't be using it here, nor advertise that they were. With option two, you know that they are using it, because you have to manually install the application to run the protocol.
Personally, I think its great to think about protocols and the tech that goes into it... but only because its interesting to me technically.
Some of this kind of sounds like: I have a cool protocol and now Im in search of a problem that I can apply it to. What app should I duplicate first?
You need to flip this around and ask: what kind of service can I build that would deliver new or additional value to users, that is a significant enough improvement that users will switch en mass.
Then go do that, get a bunch of users, and then release your protocol and encourage others to participate.
There's nothing wrong with doing it all in parallel, but the primary problem -- getting users -- is large enough to consume all of your energy.
EDIT: Or become a protocol evangelist... write your protocol, document it well, and start advocating it and explaining the advantages... maybe you can get Lemmy and other platforms to adopt it instead of ActivityPub. You can also write up patches to add support for it to various open source projects. Let them worry about building the remaining parts of solving the social problem... there's definitely room for multiple groups to work on solving this problem together.
Protocols tend to be a good first step, but they're extremely vulnerable to abuse without something larger working atop them.
Email is a protocol. Implementation is a practical nightmare because of bad actors. Something to control bad actors is vital to any communications system, regardless of whether you classify it as "service" or "protocol."
Also, have you thought about asking your clients/whatever to use one app to communicate with you? Even if you get half of them onboard, it sounds like it would save you a lot of mental bother.
reply