
Rumble: Twitter over sneakernet - pranfaha
http://www.disruptedsystems.org/
======
jchrisa
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](http://blog.couchbase.com/photodrop)

~~~
dbof
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.

~~~
jchrisa
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.

------
jewel
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.

~~~
Tepix
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.

~~~
dbof
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.

------
Animats
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.

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

~~~
thescriptkiddie
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](https://code.google.com/p/android/issues/detail?id=82)

~~~
awqrre
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](http://www.thinktube.com/index.php/tech-en/android/wifi-ibss)

------
VikingCoder
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?

~~~
Kadin
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.

~~~
vox_mollis
And yet, everyone thinks bitcoin will scale just fine.

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

~~~
VikingCoder
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!

------
tlack
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?

------
SapphireSun
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...](http://www.nydailynews.com/news/national/rumblr-tinder-fighting-app-
launch-beta-nov-9-article-1.2427623)

Edit: Actual site [http://app.getrumblr.com/](http://app.getrumblr.com/)

------
Marlinski
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.

------
etrautmann
So this is like firechat with a buffer?

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

~~~
e12e
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...](https://github.com/Marlinski/Rumble/blob/master/app/src/main/java/org/disrupted/rumble/util/EncryptedOutputStream.java)

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...](https://github.com/Marlinski/Rumble/blob/262a8b0a618c9f90457f548cc81c359ca11e0d0b/app/src/main/java/org/disrupted/rumble/network/protocols/rumble/packetformat/CommandProcessor.java#L107)

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

~~~
e12e
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).]

