jami
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ring] GNU Ring to replace SMS/Whatsapp


From: Greg Troxel
Subject: Re: [Ring] GNU Ring to replace SMS/Whatsapp
Date: Wed, 10 May 2017 20:14:22 -0400
User-agent: Gnus/5.130016 (Ma Gnus v0.16) Emacs/24.5 (berkeley-unix)

Stefan Monnier <address@hidden> writes:

>> I think the big issue with text messaging and offline recipients in ring
>> is really that offline delivery tends to go with servers.  With xmpp, or
>> email, we expect the server to be online (up and on the Internet) all
>> the time, and the user then connects to get messages.
>
> [ Tho IIUC XMPP was designed in such a way that reliable offline delivery
>   requires extra work (as in implementing various extensions of the
>   base protocol) on the part of the clients and servers, so it's not
>   supported everywhere.  ]

I can see the point, but I'm not aware of clients or servers that don't
cope.

But, I tend to send xmpp only when I see presence.  On the other
hand. OMEMO as used by Silence (formely SMSSecure) works fine with
offline delivery via SMS in the cell network.

>> Ring could do this for messaging, where one has a proxy ring address
>> that's likely reachable, and then the mobile client could connect and
>> get things.  But, that's probably going far afield of the original
>> online voice call intent.  It might not be hard, sort of MX records for
>> chat destinations, signed by the original key, and fetched/delivered
>> once and cached.
>
> Another option might be to design a system where the message is sent to
> a random (set of) other node(s) in the mean time: the game is to then
> try and make sure that the message is moved/replicated in such a way
> that there's "always" at least one machine up-and-connected that has
> a copy of the message.  So there should need to be some way to keep
> track of how many replicas of each message are still online (and since
> you can't assume machines will announce their departure before going
> offline, you have to explicitly poll in order to get this information,
> which could end up very costly).
>
> Of course, some of those "other nodes" could be dedicated servers like
> what you describe, in which case the need for replication to defend
> oneself against the server going offline would be reduced.

An interesting point.  There's a whole body of work in "Disruption
Tolerant Networking" to send packets (which they call bundles) from a
node to another node, without assuming e2e connectivity.   But, I am not
aware of routing that really works in the general case.  There is
definitely a tradeoff of reliability vs how much you replicate.

https://tools.ietf.org/html/rfc4838
https://tools.ietf.org/html/rfc5050

But, I think what you are suggesitng is simpler, because it's about
replicas in the connected subset, not the full disconnected case.
This can be viewed as sort of like an intermediate step between
requiring the actual destination to be online and the bitmessage
approach.

I was specifically trying to suggest the proxy run by the mobile user as
a feasible and security-ok point that was relatively easy to get to.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]