Please excuse all the low-level detail, if inappropriate to the discussion. The protocol changes are here specified.
<div>
    <br />
</div>
<div>
    <br />
</div>
<div class=""protonmail_signature_block"">- HH</div>
<div>
    <br />
    <div>
        <div>
            <br />
        </div>On Tue, Oct 24, 2017 at 13:40, henry <<a href=""mailto:henry@callistohouse.club"" class="""">henry@callistohouse.club</a>> wrote:</div>
    <blockquote class=""protonmail_quote"" type=""cite"">In order to bring ParrotTalk-3.6 support, alongside historical 3.5 support, the frame header stays the same and the processing of the ProtocolOffered would select "ParrotTalk-3.6" to use the compact protocol of 
        <div>
            <br />
        </div>
        <div>- ProtocolOffered { offered, preferred }</div>
        <div>- ProtocolAccepted { accepted }</div>
        <div>- IWant|GiveInfo|ReplyInfo { vatId, domain, publicKey, cryptoProtocols, dataEncoders }</div>
        <div>- IAm|ReplyInfo { vatId, domain, publicKey, cryptoProtocol, dataEncoder, dhParam }</div>
        <div>- Go { cryptoProtocol, dataEncoder, dhParam, signature }</div>
        <div>- GoToo { signature }
            <br />
            <div>
                <br />
            </div>
            <div>Using eLinda :</div>
            <div>
                <br />
            </div>
            <div><a href=""http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz"">http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz</a>
                <br />
            </div>
            <div>
                <br />
            </div>
            <div>Above the FrameBuffer, below the SessionOperations for each version of the protocol, an ELindaSession could be inserted. This session think would have the stacks for each protocol version SessionOperation registered by protocol in a Tuple,
                for eventual callback. When the ProtocolOffered comes in we publish the tuple frame, with set selected version, to route to the correct SessionOperation to support each version of the protocol.</div>
            <div>
                <br />
            </div>
            <div>With a non-specific vatId required, anonymous connections would be supported.</div>
            <div>
                <br />
            </div>
            <div class="""protonmail_signature_block""">- HH</div>
            <div>
                <br />
                <div>
                    <div>
                        <br />
                    </div>On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse <<a href="""mailto:stepharo.self@gmail.com""" class="""""">stepharo.self@gmail.com</a>> wrote:</div>
                <blockquote class="""protonmail_quote""" type="""cite""">Hi henry thanks for this announce. Can you tell where such protocols are used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry
                    <henry@callistohouse.club>wrote: > Hi all, > > I am happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and Pharo, found here: > > http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows this
                        specification: > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFrameDesign-3.5.pdf > > One item of note, in version 3.5, the system connecting to a server, sending > the IWant msg, must know
                        the vatId of the system being connected to. I am > considering changing this to version 3.6 by removing one round-trip in > messaging. Therefore, these messages would be combined: IWant/GiveInfo, > IAm/ReplyInfo. I will
                        keep ProtocolOffered and ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and 3.6. > > Thoughts please? > > - HH
                    </henry@callistohouse.club>
                </blockquote>
            </div>
        </div>
    </blockquote>
</div>