> The RemotePromises traffic is for export/import of FarERefs, async/eventual message sending and remote GC. RemotePromises has a “RemoteObjectMemory” (Scope with its object maps).

I should mention the RemotePromises protocol is a part of the foundation of the application layer, above en/decoding of the SecureSession layer.


Have a Good One; Keep it, Light.
Kindly,
rabbit
. .. … ‘…^,^


Sent from Callisto House :: decentralized mobile homeless solutions

> On Sep 10, 2022, at 13:03, rabbit <rabbit at callistohouse.org> wrote:
> 
> Hi Ron, great stuff! I totally get the export controls. Flipping our Crypto to libsodium avoids that problem, yes?
> 
>> We are using promises now but the encryption is part of the transport not part of the protocol.  Everything between client and server and between servers is encrypted in transport. 
> 
> This is the same with ParrotTalk, it is the transport layer with session layer, encrypted. As a session layer it pushes an ASN1 encoder thunk onto the stack for ASN1 en/decoding. The RemotePromises traffic is for export/import of FarERefs, async/eventual message sending and remote GC. RemotePromises has a “RemoteObjectMemory” (Scope with its object maps).
> 
> How are you using Promises? I’m very curious!
> 
>> Please don't take anything I'm saying as trying to dissuade you from doing your work.  I do think it has real value and can help anyone that is interested in learning more about crypto, and eventually it could be extremely useful for real world use.
> 
> No worries, Ron! I’m not mad at you! It has long been an educational implementation of encrypted data-in-motion composable stack. I think it has turned out well, a very clear, simplex implementation.
> 
>> If I use external components for computation (smart contracts is one example) I could compose systems in a completely different way.
> 
> 
> I totally agree! Composing systems with Async Promises and Reactors is a completely different style. I think of the different style of Continuation-passing style, as an analogy. I wish to develop this style further.
> 
> So I have decided not to put a naming service/user registration & login in the ParrotTalk v3.8 protocol. J will add a connect service and bridging and double encryption to allow for third party “msg send routing”. The naming service / user registration / user login will be implemented using RemotePromises, so at the application layer.
> 
> Once I get my SPADS Server working with frame probing! It works for Protocol negotiation (ProtocolOffered & ProtocolAccepted) and v3.6 handshake. 
> 
> Have a Good One; Keep it, Light.
> Kindly,
> rabbit
> . .. … ‘…^,^
> 
> 
> Sent from Callisto House :: decentralized mobile homeless solutions
> 
>>> On Sep 10, 2022, at 10:12, Ron Teitelbaum <ron at usmedrec.com> wrote:
>>> 
>> 
>> Hi Rob,
>> 
>> Looking forward to talking with you on Monday!  We will probably not be able to use your code.
>> 
>> The reason is pretty basic.  We are only using OS provided crypto.  Because we are not including actual crypto code in our system we don't have any export restrictions from the US Government.  It also increases security because it allows customers to update their code in the regular course of business.  When we first started our TLS implementation I had intended to use it, but after talking with Andreas we decided that it was better to not export crypto.  That was why Andreas wrote the SqueakSSL code.  
>> 
>> We are using promises now but the encryption is part of the transport not part of the protocol.  Everything between client and server and between servers is encrypted in transport. 
>> 
>> I do believe that eventually having a secure remote messaging ability will be beneficial.  It is closer to Alan's vision of programs as computers being able to communicate much like a smart internet.  People don't think that way today and it is very possible it's not happening today because of security and performance guarantees.  Please don't take anything I'm saying as trying to dissuade you from doing your work.  I do think it has real value and can help anyone that is interested in learning more about crypto, and eventually it could be extremely useful for real world use. If I use external components for computation (smart contracts is one example) I could compose systems in a completely different way.  If that starts to happen it could lead to people building better and better components and making them available for people building systems.  It's a very interesting future!
>> 
>> All the best,
>> 
>> Ron 
>> 
>>> On Sat, Sep 10, 2022 at 9:41 AM rabbit <rabbit at callistohouse.org> wrote:
>>> Hey Ron, good morning to ya!
>>> 
>>> I’ve scheduled a demo with you! Here is my ParrotTalk spec for v3.7 [1]. 
>>> 
>>> Here is sample code using Async msg sending with Promises, two Async sends followed by a reactor registration:
>>> 
>>>     ((42 eventual *10) ^ 100)
>>>         whenResolved: [:result | 
>>>             Transcript cr; 
>>>                 show: ‘The result is ‘, 
>>>                     result printString]
>>> 
>>> [1] ParrotTalk v3.7 protocol specification - 
>>> 
>>>>> We are using TCP secure sockets now with our own protocol to do an overlay network to allow for network prioritization.
>>> 
>>> Do you have a protocol specification I could read?
>>> 
>>>>>> The overlay network allows us to limit traffic to what is most important.  Since we are not passing a huge amount of data we don't use UDP.
>>> 
>>> What is this? UDP allows for more bandwidth? Very interesting! Huge amount of data? How much? Live Video?
>>> 
>>> 
>>> Have a Good One; Keep it, Light.
>>> Kindly,
>>> rabbit
>>> . .. … ‘…^,^
>>> 
>>> 
>>> Sent from Callisto House :: decentralized mobile homeless solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220910/f4bc631d/attachment.html>