Re: peer-to-peer hga@xxxxxx (14 Oct 2019 18:50 UTC)
Re: peer-to-peer Amirouche Boubekki (15 Oct 2019 09:37 UTC)
Re: peer-to-peer hga@xxxxxx (15 Oct 2019 13:41 UTC)
Re: peer-to-peer Amirouche Boubekki (15 Oct 2019 16:56 UTC)
Re: peer-to-peer hga@xxxxxx (15 Oct 2019 18:35 UTC)
Re: peer-to-peer Arne Babenhauserheide (18 Oct 2019 22:32 UTC)
Re: peer-to-peer Amirouche Boubekki (19 Oct 2019 07:22 UTC)
Re: peer-to-peer Arne Babenhauserheide (19 Oct 2019 20:41 UTC)

Re: peer-to-peer hga@xxxxxx 15 Oct 2019 18:35 UTC

> From: Amirouche Boubekki <xxxxxx@gmail.com>
> Date: Tuesday, October 15, 2019 11:56 AM
>
> Le mar. 15 oct. 2019 à 15:41, <xxxxxx@ancell-ent.com> a écrit :
>
> [ Supernodes. ]
>
>>>>> A peer initiating a request must wait for a reply at most 5 seconds.
>>>>
>>>> Another hard limit that should be thought about.  Colonies on the
>>>> Earth's moon, and in space in our Earth-Moon Lagrangian points,
>>>> are close enough to consider including in the remit of this system
>>>> (https://en.wikipedia.org/wiki/Lagrange_point_colonization), and
>>>> let's say they enforce a minimum round trip of ~2.5 seconds.
>>>>
>>>> I can imagine terrestrial situations where a long round trip is
>>>> possible, although I'm not sure they'd be suited for this protocol.
>>>
>>> This is not IPFS. My idea behind this protocol is to solve today's
>>> problems.
>>
>> Which is why I didn't suggest trying to include other planets like
>> Mars, where a round trip varies from 8 to 40 minutes.  Allowing for an
>> extra 2.5 seconds for the Earth-Moon region strikes me as a rather
>> small accommodation, which might be useful for some situations on Earth.
>
> In that case yes. It can be made 10 seconds given the applications I
> have in mind ie. applications that are not real-time.

Excellent, let's not discriminate against the spacenoids to be.

> This make me think I should find a better name than 'peer-to-peer'.

I have to say this is the first time I've seen the concepts of
"peer-to-peer" and "real-time" together.  I'd expect things to be
fairly fast once you've accumulated a set of peers with metrics for
"distance" or more like responsiveness, outside of the file sharing
context where large chunks of data are being exchanged ... but what
sort of delays would this likely have?  For what applications would
people find the various delays, startup, "normal", lost a peer, etc.
etc. tolerable?

E.g. a lot of social media sounds hard without preemptively sending a
fair amount of data, although if that's text the sending shouldn't be
too expensive.

- Harold