Apparently so. It uses DTLS, but I'm not sure where the certificates for that would come from or how their authenticity is verified. If it's all self-signed, then your best solution is TOFU (trust on first use). Otherwise your confidentiality and integrity are completely dependent on your network position.
Messages are not end-to-end encrypted, and this is not an anonymous system. See below for more details. We use the term 'secure' here to mean that we do not use plaintext transports.
Although to my admittedly meagre security knowledge, I would've assumed that "no plaintext transports" would mean it was encrypted end-to-end.
I really really really don't recommend outsourcing your security architecture to interested passers-by if that's going to be a core feature of your project.
> When you send messages, they're signed with your SSH key
It seems to me that they're encrypted with your private key and paired with "username". The client then attempts to decrypt using the public key associated with that username on github.
In this system, the receiver and any MITMs (okay, so everyone) know it came from "the real grrowl according to github" — authenticated but not confidential at all.
First, you're describing RSA signatures. "Encrypt X with your private key" means "X^D mod N" which is how RSA signatures work. In the context of RSA-based cryptosystems, it's clearer to just say "signed".
Second, the ghsign library uses the `RSA-SHA1` signer, which runs the message through SHA1 before signing it. The reason it does this is because "textbook" RSA (i.e. RSA on arbitrary messages) is vulnerable to chosen-plaintext attacks.
Poor nullsoft. Milkdrop is still the best music visualiser available, NSIS is still(!!!) being updated (last release October 2014), and they just did Great Work until AOL came along. So sad.
But, why does something saying it is p2p always seem to have some centralized dependency? In this case, it's GitHub auth.
It seems that the initial authentication of you are who you say you are could be done via transferring a key to someone- by email, flash drive, whatever- and then after that, as long as you could connect to them, you could talk to them- with no other dependency except the network itself, which may involves a lot of significant dependencies, or may not, e.g. a cross-wired cable.
Because key distribution is a pain. That said, it would be neat if you could choose centralized keystore. That would mean that you would get one account per online service, but the communications could be multiplexed.
> Simply put, this is a proxy server that works behind a NAT, even when the client is behind a different NAT, without any 3rd party or network changes.
> There is no middle man, no proxy, no 3rd party, no UPnP/STUN/ICE required, no spoofing, and no DNS tricks.
Ok, so does this really work?
Yes. Try it!
I'm confused. This can't work.
You should be, and it does work.
But it can't. My NAT blocks incoming packets and so will the other.
I know.
It's clever, but not exactly relevant to the GP's comment. pwnat requires the initiator to know the IP of the target host, so some form of external seeding is still required.
The number one thing I'm looking for in an open-source Skype alternative is persistent group chats with history (so when you sign in, you're still in the same group chats you were, and the history of messages that were sent in that chat while you were gone are sent to you). I'm baffled that this seemingly necessary thing is such a rare feature, and I'd be all over this project if it gets this.
We thought the exact same thing, so we're creating Matrix [1]! It supports all sorts of things, but especially public/private group chats with multiple device support. We're basically a team of people who use IRC all day, so we really do feel your pain :)
I know this might sound snarky, but this is the combination a lot of my peers and I use.
I'm wary of the "yet another proprietary new messenger", all of which are only compatible with themselves. I can not understand why none of them implement protocols all the messengers can agree upon like for example tent.io, remoteStorage or ZeroNet.
Distributed messaging is hard and a lot of people are giving it a try, leaving us with lots of different half baked walled gardens. Yes, I'm looking at you, threema, telegram and your friends...
Don't websockets require a server to work ? You can't just directly connect to an host (obviously to prevent malicious scripts, I guess) using js.
So if I understand it right, if you make a P2P app in js using websockets, it still requires a server to spread IPs between hosts. So it's "decentralized", but you could still track users since the server has everybody's address.
So when you chat, it's P2P, but when you start it up, it's still centralized.
Unlike kamdelia, bitcoin, bittorrent, bitmessage, you could still shut this down if it uses js. Not very interesting.
Exactly what I thought. WebRTC has this limitation and it's not actually possible to implement a DHT on top of it. Not sure why the developers decided to use WebRTC. I mean, it's a good transport layer for real-time communication (where bandwidth is a limited resourced), but not for decentralization.
This sounds a lot like the spirit of Skype in its early days.
I could be wrong but now that the latter has been integrated into Microsoft's tools, I think there's an open gap for what Skype used to provide: a friendly P2P chat tool.
Tox[1] is aiming to fill that gap. It works, and although it hasn't been properly audited (that I know), most people agree that it's reasonably secure and anonymous. It's also completely p2p with no federation of any kind.
It has a ways to go in the way of frontends and mobile support, but it works. The biggest feature it's missing is proper synchronization of your profile between devices (which is a development priority). That and it has a small network of users, so you won't be talking to your mom over Tox.
* Non-repudiable. Everything you send is signed with the public key on your GitHub account.
* Uses SHA1. (via the ghsign NPM module)
* Uses mDNS and BlueTooth LE and a gossip topology algorithm, so I'm not sure what would prevent a random third party from eavesdropping.
I would hesitate to market this as "secure".