[guardian-dev] Messaging Moving Forward

[Hans-Christoph Steiner]

I like the general idea of the actual contact address being something that
changes frequently, and is then communicated to contacts when there is a live
connection between them, something like "next time we talk, call me at
987239871ef1b123b".  There are two hard problems here:

1) how do you find new contacts?  If you give a new contact the address
908a80a8b10810fe0, then you need to keep that one active until that contact
makes the connection.  What if they never do, or it takes them a few months?
Then you have something that is basically the same as the standard long-lived
registration.

2) what about contacts that are not regularly talking to each other?  Or there
is a long gap in correspondance?  Its again the problem above, you need to
keep a long lived ID, otherwise you'll loose contact.

.hc

On 05/18/2013 07:41 AM, Timur wrote:
> Hi Lee, yes sure, infrastructure is needed. All I'm saying is that the
> infrastructure does/should not need to demand registration.
> Example: (A) connects to the chat infrastructure and submits one or more of
> it's identities:
> 
> # Hi, I'm available as "124gf3e3210d09ef", "0d03e32135a7f9a" and
> "af23617db12a7751".
> 
> On the client's terminal, this would be phrased as: "You can now be connected
> by (B), (C) and (D)." Some time later (B) connects to the chat infrastructure
> and also submits one or more of it's identities. But in addition, it also
> requests a connection to (A):
> 
> # Hi, I'm available as ...., .... and ....; also please connect me to
> "124gf3e3210d09ef".
> 
> On the client this would be phrased as "You can now be connected by (A), (E)
> and (F). On your request, you will now be connected to (A). Zing. On other
> occasions, (A) and (B) may connect to the chat infrastructure using completely
> different identities (unique addresses) - which may be known (only) to other
> clients. (A) and (B) route their (encrypted) communication through the chat
> infrastructure. But it would be far more difficult (for 3rd parties) to track
> their activity. To me, that would make a big difference (compared to, say,
> XMPP). Especially in the long run.
> - Timur
> 
> On 18.05.2013 04:44, Lee Azzarello wrote:
>> Timur, the infrastructure is there because I'm guessing that 50% of
>> all IP addresses on the Internet are behind a NAT. The remainder of
>> address space is used up. If you do synchronous networking, you're
>> going to need each end to be able to transmit and receive at any time.
>> But I don't think that's what Hans is talking about. He's talking
>> about a unique address belonging to a registered user and that user
>> registering for that address through a client application.
>>
>> -lee
>>
>> On Fri, May 17, 2013 at 8:05 PM, Timur Mehrvarz
>> <timur.mehrvarz at riseup.net> wrote:
>>> On 05/18/2013 01:07 AM, Hans-Christoph Steiner wrote:
>>>> XMPP servers support self-registration, so really the only hard part there is
>>>> getting the sign-up UX right.
>>> Why ask for registration at all? If the parties know how to address each
>>> other uniquely, then technically, there is no need for them to register.
>>> All they need is a "helping hand". Say, A and B have had a conversation.
>>> Some time later, A and C will have one. Why make the infrastructure
>>> aware of the fact, that A is the same party in both (all) cases? I
>>> assume that A's address known to B can be different from A's address
>>> known to C.
>>>
>>> - Timur
>>>
>>> _______________________________________________
>>> Guardian-dev mailing list
>>>
>>> Post: Guardian-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>
>>> To Unsubscribe
>>>          Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>>          Or visit:
>>> https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>>>
>>>
>>> You are subscribed as: lee at guardianproject.info
>