Pirate Bay co-founder aims to launch surveillance-proof messaging app Hemlis(thenextweb.com)
thenextweb.com
Pirate Bay co-founder aims to launch surveillance-proof messaging app Hemlis
http://thenextweb.com/apps/2013/07/10/hemlis/
19 comments
Or Gliph. Which is far slicker than all of those combined.
Although, not OS I believe, sadly.
https://gli.ph/
Although, not OS I believe, sadly.
https://gli.ph/
Co-founder of Gliph here, thanks for mentioning our work.
We understand that some folks require open source for their secure messaging, and encourage them to seek out solutions that provide that. We encourage more options overall for secure communications.
Gliph isn't just a secure messaging tool. Our mission is to help individuals transact with their peers in a trusted, efficient and delightful way.
Gliph is the easiest way to send Bitcoin, and the only app in the App Store that officially supports sending Bitcoin P2P.
Secure communication with strong privacy controls is a fundamental requirement to accomplish our goal.
We understand that some folks require open source for their secure messaging, and encourage them to seek out solutions that provide that. We encourage more options overall for secure communications.
Gliph isn't just a secure messaging tool. Our mission is to help individuals transact with their peers in a trusted, efficient and delightful way.
Gliph is the easiest way to send Bitcoin, and the only app in the App Store that officially supports sending Bitcoin P2P.
Secure communication with strong privacy controls is a fundamental requirement to accomplish our goal.
[deleted]
Openness is important, but it's not enough for success. People will use Hemlis because it looks pretty and because it's backed by Peter Sunde and the other TPB guys. Or maybe they won't, because all of their friends use Whatsapp.
If Surespot had group chat I might consider it. Do any of the privacy-focused messengers support encrypted group chats?
If Surespot had group chat I might consider it. Do any of the privacy-focused messengers support encrypted group chats?
Can you please describe the target group of people who will need an ecnrypted group chat?
I'm asking because I've made secure alternative to e-mail ResoMail, but I don't see a large pool of users ready to switch to secure comunications.
I'm asking because I've made secure alternative to e-mail ResoMail, but I don't see a large pool of users ready to switch to secure comunications.
In my opinion, all private communication should be safe from eavesdroppers. For
one on one chats, many applications implement encryption through OTR or PGP.
I haven't found anything comparable for group chats, though.
I'm asking because I've made secure alternative to e-mail ResoMail, but I don't see a large pool of users ready to switch to secure comunications.
For me it's a matter of convenience and network effects. Do I have to enter a passphrase every time I send a message? Do I need yet another client for this proprietary IM network? Does the client implement the features I expect? As for your software, first of all, it's great that you're working on it. These are the questions that come to my mind:
What are the benefits of ResoMail compared to email + PGP? You should explain why it's necessary to break compatibility.
Can I trust it? People who really need cryptography will use software that they know is reliable, e.g. a version of GnuPG that has been audited by an expert. How do I know your implementation is secure? It's not enough to state that it's open source.
You say it's open source, but where is the source code?
Is the traditional email client UX still the best way to go? Is it accepted by users who grew up with Facebook and expect less friction?
I'm asking because I've made secure alternative to e-mail ResoMail, but I don't see a large pool of users ready to switch to secure comunications.
For me it's a matter of convenience and network effects. Do I have to enter a passphrase every time I send a message? Do I need yet another client for this proprietary IM network? Does the client implement the features I expect? As for your software, first of all, it's great that you're working on it. These are the questions that come to my mind:
What are the benefits of ResoMail compared to email + PGP? You should explain why it's necessary to break compatibility.
Can I trust it? People who really need cryptography will use software that they know is reliable, e.g. a version of GnuPG that has been audited by an expert. How do I know your implementation is secure? It's not enough to state that it's open source.
You say it's open source, but where is the source code?
Is the traditional email client UX still the best way to go? Is it accepted by users who grew up with Facebook and expect less friction?
People will emotionally react and download a beautiful secure app because privacy is a hot topic right now. The market could be quite large if opinion leaders use this app.
also promising: http://kontalk.org/
It's only for android.
He's working on an iOS version too. Plus, it's open source so other people can write clients for other operating systems if they want.
[EDIT]: https://www.facebook.com/surespot/posts/614633905213667
26th June: "Just sent first successful surespot encrypted message from iPhone to Android."
[EDIT]: https://www.facebook.com/surespot/posts/614633905213667
26th June: "Just sent first successful surespot encrypted message from iPhone to Android."
It's open source. Fund it and it'll get ported to other platforms =)
I don't see how hemlis is worse though? It's even better since it's funded.
It's worse because:
1.) It's not open source
2.) They want to charge for certain features that are free in surespot.
(on top of the $100k they're already asking for)
3.) They wont let you run your own serverhemlis looks better though.
Just adding another open-source (Android only, for now) competitor from WhisperSystems (Moxie Marlinspike), including a secure-voice app:
https://whispersystems.org/
https://github.com/WhisperSystems
Moxie is supposedly working on an iOS version. The Android version is fairly seamless and can still contact users not using the app -- wire insecure. The local storage is encrypted, regardless of your contact -- again, you run the risk of wiretapping, if the other end does not share the use of the app.
https://whispersystems.org/
https://github.com/WhisperSystems
Moxie is supposedly working on an iOS version. The Android version is fairly seamless and can still contact users not using the app -- wire insecure. The local storage is encrypted, regardless of your contact -- again, you run the risk of wiretapping, if the other end does not share the use of the app.
Ever since the cryptocat fiasco I'm quite wary of trusting these kind of apps, that seem to be appearing like mushrooms lately.
Can anyone with any crypto know-how comment on the security of WhisperSystems?
I'll let the crypto guys comment, but my understanding is that Moxie is no pushover in that arena.
The following are the protocols used by WhisperSystems:
https://github.com/WhisperSystems/TextSecure/wiki/Protocol
https://github.com/WhisperSystems/RedPhone/wiki/Encryption-P...
The following are the protocols used by WhisperSystems:
https://github.com/WhisperSystems/TextSecure/wiki/Protocol
https://github.com/WhisperSystems/RedPhone/wiki/Encryption-P...
Moxie the founder of whisper systems is for real, and whisper systems is owned by twitter now and I'm not sure how much they are supporting it.
Silent Circle is Phil Zimmerman who is also for real (PGP real).
Trust apps that are developed by heavies with a history of first class crypto work. Be wary when a group of people with limited crypto experience launches a secure communications app especially if the app runs in the browser.
Silent Circle is Phil Zimmerman who is also for real (PGP real).
Trust apps that are developed by heavies with a history of first class crypto work. Be wary when a group of people with limited crypto experience launches a secure communications app especially if the app runs in the browser.
Moxie Marlinspike is the real deal.
This is a terrible thing that they are trying to cash in on a closed, centralized solution based on proprietary GUI for only iOS / Android.
I'm very disappointed and thought the TPB guys would no better. Sad day...
Worst part is that people will fund them withing 24h!
But I guess just like 1 in 2 Kickstarter project, it's a quick sell so you can eat, but this brings nothing to the security/privacy table unless they come clean...
But I guess just like 1 in 2 Kickstarter project, it's a quick sell so you can eat, but this brings nothing to the security/privacy table unless they come clean...
....why not just run OTR on top of Jabber? It's pretty surveillance proof and they are applications for iOS/Android that support all of that.
I fail to see the point.
I fail to see the point.
> why not just run OTR on top of Jabber?
Indeed, on the face of it hemlis looks like a step backwards. There's a chance it might not be, though.
The most straightforward way for them to combine PGP + XMPP would be to encrypt and sign every message with the parties' static PGP keys. If you do that, you lose both the perfect forward secrecy and repudiability you get with OTR. [0] Those are important properties.
However, if they're planning to derive ephemeral keys for each conversation, as suggested by tptacek [1] and others, then things get more interesting.
OTR + Jabber still seems weak to me in two areas:
1. OTR's solution to the authentication problem is for the two parties to agree, out-of-band, on a shared secret [2]. I don't think normal users are going to do a good (secure) job of this. Key introduction through a web of trust, aka PGP, would make for a better and more secure user experience.
2. The reliance on a central server brokering messages is a problem. In fact the authentication in OTR version 1 was so broken that a jabber server plugin existed for MITM'ing OTR conversations [3]. Also, as another commenter points out, with a central server an agency might still be able to collect Verizon-style conversation metadata. I'd rather see something p2p along the lines of freenet or i2p.
Finally, I'm not sure what their plans are for hemlis, but there's no way I'd use a closed-source app for secure messaging. And I don't think it solves the world's problems -- we need to be able to trust this thing. That's the whole point.
[0] http://www.cypherpunks.ca/otr/otr-wpes.pdf
[1] https://news.ycombinator.com/item?id=6004510
[2] http://www.cypherpunks.ca/~iang/pubs/impauth.pdf
[3] http://www.ejabberd.im/mod_otr
Indeed, on the face of it hemlis looks like a step backwards. There's a chance it might not be, though.
The most straightforward way for them to combine PGP + XMPP would be to encrypt and sign every message with the parties' static PGP keys. If you do that, you lose both the perfect forward secrecy and repudiability you get with OTR. [0] Those are important properties.
However, if they're planning to derive ephemeral keys for each conversation, as suggested by tptacek [1] and others, then things get more interesting.
OTR + Jabber still seems weak to me in two areas:
1. OTR's solution to the authentication problem is for the two parties to agree, out-of-band, on a shared secret [2]. I don't think normal users are going to do a good (secure) job of this. Key introduction through a web of trust, aka PGP, would make for a better and more secure user experience.
2. The reliance on a central server brokering messages is a problem. In fact the authentication in OTR version 1 was so broken that a jabber server plugin existed for MITM'ing OTR conversations [3]. Also, as another commenter points out, with a central server an agency might still be able to collect Verizon-style conversation metadata. I'd rather see something p2p along the lines of freenet or i2p.
Finally, I'm not sure what their plans are for hemlis, but there's no way I'd use a closed-source app for secure messaging. And I don't think it solves the world's problems -- we need to be able to trust this thing. That's the whole point.
[0] http://www.cypherpunks.ca/otr/otr-wpes.pdf
[1] https://news.ycombinator.com/item?id=6004510
[2] http://www.cypherpunks.ca/~iang/pubs/impauth.pdf
[3] http://www.ejabberd.im/mod_otr
If the problem in OTR is we can't rely on users to verify who each other are, then any solution is going to inherit exactly the same problem because the only solution to it is external trusted parties.
On top of that, PGP is exactly a step backwards if you're worried about just observation of metadata because PGP with web-of-trust cryptographically ties every message you send forever back to the key which sent it. OTR on the other hand treat the keys as inherently disposable and relies on the only correct verification protocol which is user knowledge of each other.
You have to choose which problem you find more important: either you can be very anonymous, or very sure of who you're talking to but never both.
On top of that, PGP is exactly a step backwards if you're worried about just observation of metadata because PGP with web-of-trust cryptographically ties every message you send forever back to the key which sent it. OTR on the other hand treat the keys as inherently disposable and relies on the only correct verification protocol which is user knowledge of each other.
You have to choose which problem you find more important: either you can be very anonymous, or very sure of who you're talking to but never both.
> If the problem in OTR is we can't rely on users to verify who each other are...
Not what I'm saying here. I think the specific way they've chosen to verify a new party in OTR -- by agreeing on a shared secret through some other channel -- is a bad user experience with security implications. Normal people will choose dumb, guessable secrets. Or send them over insecure channels.
I think the equivalent of an in-person PGP key signing has a better chance of succeeding. If we're talking about an app, one person's phone could display a QR code of their pubkey, and the other could scan that in to import it.
As with PGP, once the web of trust has a backbone (composed of hardcore early adopters like us here on HN), you can skip the in-person step, and trust keys that enough of your contacts trust.
OTR doesn't have this network effect.
> The only solution to it is external trusted parties.
Sure. But who those external trusted parties are is the crux of the issue.
Is it a browser maker and a couple companies you don't get to choose? Who are perhaps cooperating with some government (hey, it's happened)? Or is it people you actually choose and choose to trust?
> On top of that, PGP is exactly a step backwards if you're worried about just observation of metadata because PGP with web-of-trust cryptographically ties every message you send forever back to the key which sent it.
I mentioned this in the grandparent: with PGP, you could also derive ephemeral keys for the conversation, as OTR does.
> You have to choose which problem you find more important: either you can be very anonymous, or very sure of who you're talking to but never both.
Not so. You can both be anonymous from the man-in-the-middle's perspective, but can also verify each other. Look at how OTR does it. The "Socialist Millionaire's Protocol."
http://en.wikipedia.org/wiki/Socialist_millionaire
Not what I'm saying here. I think the specific way they've chosen to verify a new party in OTR -- by agreeing on a shared secret through some other channel -- is a bad user experience with security implications. Normal people will choose dumb, guessable secrets. Or send them over insecure channels.
I think the equivalent of an in-person PGP key signing has a better chance of succeeding. If we're talking about an app, one person's phone could display a QR code of their pubkey, and the other could scan that in to import it.
As with PGP, once the web of trust has a backbone (composed of hardcore early adopters like us here on HN), you can skip the in-person step, and trust keys that enough of your contacts trust.
OTR doesn't have this network effect.
> The only solution to it is external trusted parties.
Sure. But who those external trusted parties are is the crux of the issue.
Is it a browser maker and a couple companies you don't get to choose? Who are perhaps cooperating with some government (hey, it's happened)? Or is it people you actually choose and choose to trust?
> On top of that, PGP is exactly a step backwards if you're worried about just observation of metadata because PGP with web-of-trust cryptographically ties every message you send forever back to the key which sent it.
I mentioned this in the grandparent: with PGP, you could also derive ephemeral keys for the conversation, as OTR does.
> You have to choose which problem you find more important: either you can be very anonymous, or very sure of who you're talking to but never both.
Not so. You can both be anonymous from the man-in-the-middle's perspective, but can also verify each other. Look at how OTR does it. The "Socialist Millionaire's Protocol."
http://en.wikipedia.org/wiki/Socialist_millionaire
But the channel has to be OpenSSL, right? Can't they at least enable forward secrecy in OpenSSL for the chat "sessions"?
They could, but with an OpenSSL channel comes SSL PKI, and CA certs we may not want to trust.
It is possible to use OpenPGP certs with TLS, although I've never seen this done myself.
http://tools.ietf.org/html/rfc6091
It is possible to use OpenPGP certs with TLS, although I've never seen this done myself.
http://tools.ietf.org/html/rfc6091
One big problem with this approach is a lack of push notifications/persistent connections on the iOS side. On the Android side you can have something like Gibberbot running all the time and providing you notifications of new messages, but since iOS still lacks true multitasking, if you don't have your XMPP client open and in the foreground, you go offline and can't receive messages/notifications anymore.
I agree with everyone that this should be open-source, but at least this has one benefit over the other proprietary solutions out there: This is not just a secure messenger, but also a beautiful one. If you want to convince - and I do - those who use Facebook Messenger and iMessage and don't necessarily consider their privacy, it needs to have a great user experience on top of the technical foundation. On the other hand, if it gets that and ends up being open-sourced, it would be a great fit for Aral Balkan's Codename Prometheus: http://aralbalkan.com/notes/codename-prometheus/
If you want this functionality now: http://threema.ch/en/
Exactly.
You have SMS style messages (text, images, offline support) that are end-to-end encrypted (verifiably, despite being closed source). iOS and Android; group chat coming; desktop coming; Interesting feature that aids in authentication (scan each others' QR code for auth, etc); $2.
While it has more attack surfaces than OTR, it's 10x more convenient: No need to agree to anything before-hand (most likely insecurely), no need to keep anything running (offline support via threemas servers which only see metadata and ciphertext); no setting up jabber services. This is a nonstarter for unsophisticated users (whom we desperately need to help flood NSA with ciphertext, and whom I rather chat with in anything but plaintext).
While not as battle tested as GPG, it's trivial to set up -- already got my tech friend, my non tech mom, my non tech cousin on it. Has forward secrecy. I still haven't figured out Inline PGP vs S/MIME vs PGP mime. Neither has K9Mail + APG apparently. I hope soon to be recommending bitmessage over email/GPG.
I wish, oh how I wish, there were a way that open source projects could charge $2 bucks and be continually improving their services and solving both the engineering and usability of crypto products. Now or never folks: The next NSA scandal might be too late.
You have SMS style messages (text, images, offline support) that are end-to-end encrypted (verifiably, despite being closed source). iOS and Android; group chat coming; desktop coming; Interesting feature that aids in authentication (scan each others' QR code for auth, etc); $2.
While it has more attack surfaces than OTR, it's 10x more convenient: No need to agree to anything before-hand (most likely insecurely), no need to keep anything running (offline support via threemas servers which only see metadata and ciphertext); no setting up jabber services. This is a nonstarter for unsophisticated users (whom we desperately need to help flood NSA with ciphertext, and whom I rather chat with in anything but plaintext).
While not as battle tested as GPG, it's trivial to set up -- already got my tech friend, my non tech mom, my non tech cousin on it. Has forward secrecy. I still haven't figured out Inline PGP vs S/MIME vs PGP mime. Neither has K9Mail + APG apparently. I hope soon to be recommending bitmessage over email/GPG.
I wish, oh how I wish, there were a way that open source projects could charge $2 bucks and be continually improving their services and solving both the engineering and usability of crypto products. Now or never folks: The next NSA scandal might be too late.
I've just bought this for iOS, looks very interesting.
This clearly highlights one of the big challenges for mass market surveillance proof apps - there are too many obscure alternatives (unless one counts iMessage as one of them). Getting the critical mass of users (similar to what Whatsapp and Line accomplished) will be a huge challenge.
I seriously think a software like this should most definitely be open source for it to be trustworthy.
This is probably a rookie question, but how is this surveillance proof, and how would it be different from iMessage? The article mentions "Apple recently publicly stated that its iMessage service is encrypted end-to-end". Isn't something that is encrypted end-to-end surveillance proof?
First off, iMessage isn't open source, and Apple hasn't published details of the protocol either, so we don't know if their statements on the security of iMessage are actually true.
Even without knowing all the details, there are some concerning things we can observe about iMessage:
http://blog.cryptographyengineering.com/2013/06/can-apple-re...
Even without knowing all the details, there are some concerning things we can observe about iMessage:
http://blog.cryptographyengineering.com/2013/06/can-apple-re...
CyanogenMod and Moxie are working on something similar, I believe - end to end encryption with PGP, but it may work with more than just one chat app:
https://plus.google.com/+CyanogenMod/posts/23vfN2qdZTu
https://plus.google.com/+CyanogenMod/posts/jnZSBV96wxU
https://plus.google.com/+CyanogenMod/posts/23vfN2qdZTu
https://plus.google.com/+CyanogenMod/posts/jnZSBV96wxU
This project wouldn't need $100,000.
I wish Google would just do something like this themselves with Hangouts.
I don't even think they aren't doing this because they plan to offer ads related to Hangouts chats or whatever. I think it has more to do with the "features" of Hangouts, such as saving your logs - forever. Think of it like how Facebook wants to keep all the data forever so they can do something like the Timeline.
I get there can be some benefits if the chats run through their servers and everything is stored, but I'm not sure they are that huge, especially now, when all governments are seeking direct access, or to scoop up everything from all users. I think that's why Google's priority in the future should be end to end encryption for users, for most of their services.
I also hate that because governments are abusing their powers, we are forced to regress on convenience and make the services "worse" so we can be more secure. But who knows, maybe this is for the best, and the Internet is meant to evolve into something a lot more locked down and secure.
I don't even think they aren't doing this because they plan to offer ads related to Hangouts chats or whatever. I think it has more to do with the "features" of Hangouts, such as saving your logs - forever. Think of it like how Facebook wants to keep all the data forever so they can do something like the Timeline.
I get there can be some benefits if the chats run through their servers and everything is stored, but I'm not sure they are that huge, especially now, when all governments are seeking direct access, or to scoop up everything from all users. I think that's why Google's priority in the future should be end to end encryption for users, for most of their services.
I also hate that because governments are abusing their powers, we are forced to regress on convenience and make the services "worse" so we can be more secure. But who knows, maybe this is for the best, and the Internet is meant to evolve into something a lot more locked down and secure.
Why is this any different than Gnutella or I2P chat clients?
Because they have realised that it will be worthless if it can't get any marketshare.
This will have a good looking application that is easy enough for people in general to actually use.
It should be open source though. We don't need another cryptocat fiasco.
It should be open source though. We don't need another cryptocat fiasco.
No more re-inventing the wheel!
BitMessage!
https://bitmessage.org/wiki/Main_Page
BitMessage!
https://bitmessage.org/wiki/Main_Page
BM has serious problems. Currently everyone receives every (encrypted) message. This doesn't scale when there are 100.000 messages a day.
They are currently trying to find an appropriate stream implementation.
They are currently trying to find an appropriate stream implementation.
I agree, it needs some work. There is no sense in trying to fund yet-another-encrypted-messaging-application when other designs could use the help. The one linked here doesn't even say if it will be open source or free or subject to independent code audits, etc.
I thought I read somewhere that it broadcasts only to those subscribed to the broadcaster.
That should be the way it works. You can't send a message to someone unless he's subscribed to you.
That should be the way it works. You can't send a message to someone unless he's subscribed to you.
>The team is aiming to develop clients for Android and iOS
Is there BitMessage for those? The main site is telling me there is not. Google search returns some forum threads, most of them not relevant.
Is there BitMessage for those? The main site is telling me there is not. Google search returns some forum threads, most of them not relevant.
[deleted]
I will never use this.
Strangely enough, trying to click through to heml.is complains about security certificates in Firefox. Not Chrome though. Anyone else seeing this?
Needs to be an open protocol. Not just a pretty app.
Always remember this: http://xkcd.com/927/
I'm with the other reply. It's based in XMPP and PGP. Let's see how it goes. His experience is not common.
With this I don't mean he can do crypto with no error. I just mean he has some good ground about privacy and the tubes.
I'm with the other reply. It's based in XMPP and PGP. Let's see how it goes. His experience is not common.
With this I don't mean he can do crypto with no error. I just mean he has some good ground about privacy and the tubes.
I wonder how that can be "surveillance-proof". Even with e2e-encryption any product using central servers can still see who is chatting with whom, who's in your address book and what IP address your phone is connecting from. That's exactly the meta-data Verizon got accused of sharing. They might be of The Pirate Bay-fame and not share this with the NSA voluntarily, but they're not immune to being hacked or infiltrated.
What I'd probably do is split the problem -- confidentiality of messages can be ensured locally, and directory services, persistence, and foiling traffic analysis on a network service. Network service is long-lived and has much more bandwidth. It can do cool stuff like autorespond, format-convert, etc. for you. If it gets compromised, you lose traffic analysis protection, but not message confidentiality (which is end to end). You could self host the server portion or pick from a bunch of different providers.
Do traffic-analysis-resistant wasteful routing among "servers". Run constant-bandwidth from the server to the client to foil traffic analysis if you really care about that (say, messages delivered only every polling window, and every polling window, a communications of the same size/direction. That seems pretty impractical on mobile, though, so maybe use some kind of push protocol for "you have a new chat request" and then foiling traffic analysis within the chat session (when you're actively using the device). Unfortunately if you can monitor all of the network, an attacker could identify a recipient just by initiating a request and watching for a new chat opening. You could also do things like block off known travel times or other times when someone won't be in contact, correlate with message response times, and at least be able to rule in or out certain suspects (it won't help in fishing expeditions, but if you have 10k people it might be, you could probably identify a person in a few months of passive analysis).
In short, low-latency is the enemy of traffic analysis protection. A true surveillance proof system looks more like anonymous remailers and less like Tor. But, people want realtime.
Do traffic-analysis-resistant wasteful routing among "servers". Run constant-bandwidth from the server to the client to foil traffic analysis if you really care about that (say, messages delivered only every polling window, and every polling window, a communications of the same size/direction. That seems pretty impractical on mobile, though, so maybe use some kind of push protocol for "you have a new chat request" and then foiling traffic analysis within the chat session (when you're actively using the device). Unfortunately if you can monitor all of the network, an attacker could identify a recipient just by initiating a request and watching for a new chat opening. You could also do things like block off known travel times or other times when someone won't be in contact, correlate with message response times, and at least be able to rule in or out certain suspects (it won't help in fishing expeditions, but if you have 10k people it might be, you could probably identify a person in a few months of passive analysis).
In short, low-latency is the enemy of traffic analysis protection. A true surveillance proof system looks more like anonymous remailers and less like Tor. But, people want realtime.
Orbot (Tor for Android) allows you to host hidden services on your phone. My ideal IM app would be one which uses Tor to enable peer to peer delivery of messages over Tor hidden services directly between phones.
This way, not only would the message content be safe from pyring eyes, but nobody would be able to see who is talking to who or when.
This way, not only would the message content be safe from pyring eyes, but nobody would be able to see who is talking to who or when.
I totally agree! I've been working on federating XMPP over hidden services (https://blog.thijsalkema.de/blog/2013/06/11/xmpp-federation-...), but I don't give a setup like that any chance to be possible on iOS.
The end goal is to package Tor + this + an XMPP server (Prosody) into plugins for clients. It'd be a federated network running through Tor, but any XMPP-capable client will be able to use it.
Sure, you need to rely on Tor, but aside from that anybody could set up their own server easily (no hassle with DNS and SSL certs).
Sure, you need to rely on Tor, but aside from that anybody could set up their own server easily (no hassle with DNS and SSL certs).
That sounds cool. Although it's not exactly what I was talking about. In my ideal scenario phones would communicate directly with each other without having to rely on a third party server.
Surespot is open source (including the server software too), and doesn't charge you money for "advanced" features like sending images.
And surespot actually exists and is usable today.
Donate your money that way instead: https://www.surespot.me/contribute.html
(not affiliated, just a very happy user)
[EDIT] He details exactly how it works here: https://www.surespot.me/documents/how_surespot_works.html