IRC channel logs

2023-03-22.log

back to list of logs

<jar286>I think I need a desktop IRC client. In emacs it's too easy to ignore.
<tsyesika>I could never get used to using emacs as an IRC client although I know christine does it with success
<jar286>I used colloquy with some success over ten years ago. I wonder what the hip Linux users use.
<tsyesika>ACTION uses matrix's IRC bridge 
<jar286>oh yeah I looked into matrix a long long time ago.
<jar286>looks like there are tons of clients
<jar286>shall we start? I think I just want an agenda review
<tsyesika>I find that most clients I want to use don't suppose end-to-end encryption, which is fine for IRC but not for matrix <-> matrix private messages
<tsyesika>sure, let's start
<jar286> https://github.com/ocapn/ocapn/issues/36
<jar286>I've been updating the lead issue comment as I hone the agenda
<jar286>so I think I like what's there, although maybe shorten Dan's segment. He agreed to prep for 10 minutes at least, so it won't be total chaos.
<tsyesika>regarding issue 5 (core data types), the work I've been doing on the syrup serialization might be relevant as it specifies the core types it uses
<tsyesika>(syrup draft: https://github.com/tsyesika/ocapn/blob/draft-syrup/draft-specifications/syrup/syrup-specification.org )
<tsyesika>I'm planning to move that to a more obvious PR on the ocapn/syrup repo before the meeting
<tsyesika>I can comment this on issue 5 too
<tsyesika>I suspect my progress report could be 10 minutes, I don't think I'll need much time, just talk though the general scope of the three documents, time frames to deliver first drafts to the meeting
<tsyesika>maybe I'm being too much of a time optimist, I don't know
<jar286>good. zenhack seems to care about issue 5, have you coordinated? or is what you have consistent with what he suggests? I noticed something about multiple levels, I guess syrup is level 1? I haven't read the issue comments carefully, sorry
<jar286>Re time, I'm expecting questions, and we ALWAYS have the option to end early
<tsyesika>okay, sounds good
<jar286>So I'd say plan on 10 minutes and expect 20
<tsyesika>I have not coordinated with zenhack, I didn't see this issue until he mentioned it as a potential agenda item, I still have on my todo list to read through the conversation on the issue before the meeting this friday
<jar286>it could go off the rails. THat's why I want to recruit a timekeeper
<Zarutian_iPad>re #5 how little can we get away with?
<jar286>anyhow it looks like people put lots of effort into it at the time.
<tsyesika>I think the syrup document specifies a fairly small subset of "core" types (12), but I want to read the issue before commenting :)
<Zarutian_iPad>iirc in CapTP of E, quite a lot of the compound datums that #5 were omitted from the level 1 but expressed as build-calls in level 2
<jar286>I'm not in a position to talk about technical aspects. Just trying to help people move forward with it or close it.
<tsyesika>yep
<Zarutian_iPad>tsyesika: what you linked most recently fits the bill rather well I think
<tsyesika>I think the agenda looks good
<Zarutian_iPad>though I, personally would omitt the IEEE 754 floats
<jar286>wow
<tsyesika>I think there is more than enough to take the full hour
<tsyesika>wow?
<jar286>Yes, I mainly want to stimulate off-meeting activity and coordination
<jar286>People will have lots of opinions
<Zarutian_iPad>jar286: wow in response to my float comment or the meeting agenda?
<jar286>(wow re no IEEE floats.)
<tsyesika>I think the ocapn URI issue could do with user stories which hopefully will shed light on what our requirements are for them
<jar286>so, who is going to write them?
<jar286>I mean, I agree
<Zarutian_iPad>jar286: right. There are a few reasons why to omitt them from level 1
<tsyesika>I can write one/more from spritely's perspective
<jar286>I agree that we need user stories.... I also know that people much prefer discussions about technical ideas, than discussions about who is doing what, but I think we need the latter
<Zarutian_iPad>re ocapn URIs: there are at least two uses: out of band intro and persistance of long lived references.
<jar286>Oh we need some kind of designator. My question is whether they have to be URIs, and nobody has made that case as far as I can tell
<Zarutian_iPad>for the first I urge usage of ocapn:<base32> or ocapn!<base32> and try to keep them inside 512 or even 256 chars in length
<jar286>I was arguing the Waterken case at W3C, and thought the argument against caps rendered as URIs was dumb, but have changed my mind in the 12 years since
<Zarutian_iPad>a user should be able to pass an ocapn uri or sturdyref on a postit note
<jar286>Sure
<tsyesika>I think (probably due to how I framed the original issue), the discussion was split between what information and needs we have for OCapN URIs/references vs. what syntax should they have
<jar286>Postit doesn't require a URI
<jar286>Yep.
<Zarutian_iPad>hence the choice of base32
<tsyesika>I wonder if it makes sense to do what some folks where doing last meeting and discuss the requirements and try to ignore the syntax and come back to the syntax when we know what data we need to represent
<Zarutian_iPad>just the ocapn! bangtag prefix enough for that to indicate what the heck it is
<jar286>Yes. Personally I'd like to see discussion start with a document though (thus I get back to : next steps and who, not tech, at meeting)
<Zarutian_iPad>so, what is in a sturdyref or ocapn uri?
<jar286>Hmm I'm not on top of that question. I'd read the minutes. Markm seemed on top of it
<Zarutian_iPad>a way to address the hosting vat and a way to know how to ‘hear’ it ‘speak
<Zarutian_iPad>
<Zarutian_iPad>“my name is how you know it is me”
<tsyesika>at spritely currently it is:
<tsyesika>- which netlayer (e.g. tor onion netlayer)
<tsyesika>- the location (which is also the key, in this case)
<tsyesika>- the object swiss-num
<tsyesika>oh and the scheme identifies it as an ocapn URI
<Zarutian_iPad>another thing is then the object designator
<Zarutian_iPad>can be a swissNum or if it is well known freely disseminated it can be a human readable thing
<tsyesika>maybe I should assign myself to the ocapn uri issue :)
<jar286>I think we've spent too much meeting time on it already (IRC time is fine of course), so I'm looking for either a point person or subcommittee
<tsyesika>since I volunteered to write a user story
<jar286>Yes, tsyesika, self-assign anything you like please
<Zarutian_iPad>there is, if the vat is veiled (can keep secrets), another way to ‘protect’ such designators other than unguessability (picking sparsely and randomly in a huge number of possibilities in a number space)
<Zarutian_iPad>it is the nymref idea I had a while back. Basically have the hosting vat have an secret hmac key to protect the designator
<jar286>interesting
<Zarutian_iPad> https://github.com/Agoric/agoric-sdk/issues/2793
<jar286>really? 2793 issues?
<tsyesika>okay I've assigned myself to the URI issue
<jar286>excellent
<Zarutian_iPad>jar286: on the agoric sdk monorepo? not that wierd
<tsyesika>okay, is there anything else to discuss before I head off work for the day?
<jar286>Do I need to announce the agenda somewhere? We don't have an email list
<jar286>Other than that, no, go your way
<tsyesika>I have been doing it on the issue but of course if the group wants we could setup a mailing list or whatever
<jar286>OK thanks for your help
<Zarutian_iPad>there is that community.spritely.institute thread
<tsyesika>I think github can work as a pesudo-mailing list if email notifications are setup in that way
<tsyesika>*github issues
<Zarutian_iPad> https://community.spritely.institute/t/nlnet-grant-bootstraps-ocapn-protocol-standardization-effort/168/14
<RandyFarmer[m]>Perhaps his is something to discuss at the meeting? We'd be happy to host discussion on our forum, if it works better for most than GH/issues. But that would need to be a consensus of the group.
<RandyFarmer[m]>Anyone who's not a member of our forum can use OCAPN2023 as the magic cookie to get in. :-)
<RandyFarmer[m]>Certainly, all members of this group are more than welcom!
<jar286>Good option consider on Friday
<Zarutian_iPad>ACTION continues
<Zarutian_iPad>so, in ocapn sturdyrefs or uris we might also want to put in expiry at day or month granularity.
<Zarutian_iPad>you know, for the hosting vat and others to say something akin to “man, this canned pear is decades way out for its best before use date”
<jar286>'unchanelled designators' or 'channel-free designators'
<jar286>(unchanneled)
<Zarutian_iPad>(year granularity might be enough)
<Zarutian_iPad>i am still at the out of band intro usecase