Rumble: Twitter over sneakernet | Hacker News Reader

Rumble: Twitter over sneakernet

disruptedsystems.org

62 pointspranfaha27 comments

If you want to build something like this without writing the tricky code, Couchbase Lite has peer to peer sync. Our big vertical for that is currently point-of-sale but the applications are limitless.

Here's an example photo share app: http://blog.couchbase.com/photodrop

I admit I have only skimmed over the page, but...how does Couchbase create the connection? All I see is that you have to share a QR code with others, which is not really flexible compared to connecting ad hoc via Bluetooth and Wi-Fi.

In this app we use the QR code as an authentication token. The connection is handled via OS code. So BT or wifi, as you suggest.

This is really cool -- awesome work

Check out LTE direct for a potential future technology that would have a much better range than wifi and bluetooth, which could potentially make this sort of thing workable.

You could also use the upcoming LoraWAN, 802.11ah, Bluetooth 2016 (with 400% range) technologies or even packet radio... but I think using the internet (with tor) whenever its available would be a smart move.

The problem with most technologies is that they are not supported by every mobile device or by every OS, or are even not supported by the hardware. For a network where a high number of nodes is relevant, wide-spread use is crucial.

That's cute. It's basically USENET over Bluetooth.

Unfortunately, it can't use WiFi effectively, because Android doesn't allow symmetrical WiFi. You can only connect to an access point; handsets can't connect to each other. If two handsets are connected to the same access point, there can be communication.

It does not, apparently, have encryption.

I thought Android has p2p wifi (e.g., http://developer.android.com/guide/topics/connectivity/wifip...). Is this not true in practice?

Android's "p2p" wifi is an implementation of wifi direct, which has one device host an AP and the other connect as a client. Real ad-hoc mode is only possible on rooted devices, and google has been ignoring this issue for years.

https://code.google.com/p/android/issues/detail?id=82

It almost seems like Google went out of their way to disable ad-hoc Wi-Fi on Android.

http://www.thinktube.com/index.php/tech-en/android/wifi-ibss

> That's cute. It's basically USENET over Bluetooth.

Or Tor, right? It seems like it's effectively a local onion router, albeit with significantly fewer possible sources.

The problem with this, to me, is that if an adversary is targeting a certain user, they know that the actual source is in close physical proximity to whomever they actually track. That said, if they hooked this into a WiFi mesh network, things could get really interesting...

Could this be used in a large crowd? Such as a protest, or a concert? What are the scaling limitations? How does a message decide to stop propagating - wouldn't it just circle around a large crowd indefinitely?

I'm also curious how they decide to expire messages out of the database. Presumably each device doesn't carry around every message ever sent since the beginning of time; that doesn't seem like it would scale well.

And yet, everyone thinks bitcoin will scale just fine.

Not every bitcoin client needs to carry the whole blockchain for bitcoin to work.

Step one, here's how you can implement this wonderful protocol!

Step two... here's how you can hamstring the protocol, so you can use it in real life.

Hey - are we losing any of the benefits of the ideal protocol when we hamstring it?

SHHHHHHH!

Any ideas on how concepts of identity, administration, and content ownership work in networks like this? Who decides to delete an inflammatory piece of content in a completely decentralized system? Can a fate like that which befell Usenet be avoided?

I could suppose a system where identities are pinned to a key that is stored from the first time the user is identified (because a "packet" is seen from them).

But how does that stop a determined attacker from broadcasting out his fake Alice identity, so that the real Alice can no longer spread their messages?

Usually, I don't make jokes here, but that name reminded me of this (fake?) app: http://www.nydailynews.com/news/national/rumblr-tinder-fight...

Edit: Actual site http://app.getrumblr.com/

I am the developer of this program and I just noticed this thread. If you have any question about how it works I will be happy to answer.

So this is like firechat with a buffer?

This is like FireChat, but actually secure, does not leak data to any servers and works very well offline. And it is FOSS!

Maybe I'm skimming too fast, but it looks like apart from transport layer encryption (wifi/bluetooth), this uses just the nullCipher?

https://github.com/Marlinski/Rumble/blob/master/app/src/main...

Hm, looks like group-chat uses shared secret, AES CBC without any form of authentication? So I guess it's not just using null cipher. I'm not sure if I'd go as far as to call it "actually secure", though?

https://github.com/Marlinski/Rumble/blob/262a8b0a618c9f90457...

I am missing your point. Do you consider CBC with random IV value insecure? Could you elaborate on that?

Well, as far as I can figure out, there's no authentication of the plain/cipher-texts? Just an attempt at blind decryption? [ed: encryption without authentication is almost always a bad idea - I'm not clear on what's the status of the various Android versions - but I think you should be able to use AES-GCM -- which of course is a stream cipher. Not sure if one would want to frame that in order to try to leak less info about message lengths or not. I suppose one might frame the plain-text messages in 1k blocks or something before encryption, and unwrap the padding after decryption (of an authenticated cipher).]

So how does this compare to Gilgamesh, which appears to be pretty much exactly the same thing?

https://github.com/n8fr8/gilgamesh

Gilgamesh works similar, but is really only a message spreading method, which uses the Bluetooth name to spread messages. Consequently, it can only provide public messages and encryption won't also work. The devices do not connect to each other. It is the equivalent of people shouting in a crowd.

Reply on news.ycombinator.com