IRC channel logs

<Zarutian_iPad>been thinking about the bootstrap/NonceLocator that is always at each end of a captp connection

<Zarutian_iPad>if we have it semistandardized regarding which methods must be on it then the question becomes which methods

<Zarutian_iPad>I have an idea of handfull at most

<Zarutian_iPad>the .provideFor(), and .acceptFrom() is a given for the 3ph

<Zarutian_iPad>.enlivenFromSwissNum() or what ever it was called can not be used in unveiled runtime environs

<Zarutian_iPad>the others are poweless compound datum constructors for things like maps and sets iff the underlieing serialization protocol does not support such.

<Zarutian_iPad>and last but not least there are two methods that construct on the receiving end two kind of things

<Zarutian_iPad>the seqBlock constructor that basically makes an callable closeure from an depiction of straight through behaviour made up only of eventual sends.

<Zarutian_iPad>and ActiveCapCerts decoder and constructor that makes same kind of closure only the environ it is given is the safe env slightly augmented with facets to the same mechanism that .acceptFrom() and .provideFor() uses.

<Zarutian_iPad>s/facets/cert issuer specialized/spefic facets/

<Zarutian_iPad>sneek, botsnack.

<sneek>:)

IRC channel logs

2023-09-16.log