IRC channel logs
2023-01-30.log
back to list of logs
<dckc[m]>@Jacob [where did he go], presumably each of us has some vision of what to do with CapTP that brought us here. If you tell me yours, I could estimate how Agoric/Spritely interop might connect with it. <dckc[m]>you want me to play personal http proxy? :) <dckc[m]>the advogato trust metric as an Agoric smart contract has been on my mind. (taking "smart contract" in the broad sense, including paypal, venmo, and the PHP+mysql gorp I set up to help manage W3C staff allocation). I can see parts of it running in JS and parts in scheme. <ocdtrekkie>dckc: I definitely had some thoughts about Sandstorm and Spritely specifically. The Spritely demos I've seen generally have used Tor to connect directly peer to peer. But presuming Spritely can use any number of potential transports, if I wanted an HTTPS connection point for a chatroom and to keep my apps and data on my server and not tied to a client device of mine, a Sandstorm app may be a good way to do that. <dckc[m]>yes, that trust metric, Zarutian_iPad <Zarutian_iPad>as far as I can tell spritely, like E just needs bidirectional bytestreampipe to run captp on top of <ocdtrekkie>There are probably interesting options between "a Sandstorm app acts as an intermediary bridge between some peer to peer applications" and "a Sandstorm app acts as one of those peers and the Sandstorm user participates directly on the server". <dckc[m]>yes, but if you connect E's bytestream pipe to spritely's, it won't do anything useful :) <Zarutian_iPad>most of my activeCapCert and PostalRef dabblings is geared to run something akin to captp in spirit ontop of Distruption&delay Tolerand Networking <Zarutian_iPad>re datum types in ocapn: as IEEE 754 floats (big endian) were put in then why not Dec64 and posits ? <dckc[m]>I lean toward letting Cloudflare run the capnproto stuff for me :) With sandstorm, I ended up in a 1:1 user to sysadmin ratio, which is hugely inefficient. (note my trouble with backups above). And the app devs just want to docker. I am itching to try cloudflare workers and durable objects. <dckc[m]>Zarutian_iPad: why Dec64 over byte-array? <ocdtrekkie>dckc[m]: Backups is undoubtedly something Sandstorm needs to manage better in the future. The goal of Sandstorm is to allow selfhosting for non-sysadmins, which will never be possible with Docker-based solutions. <dckc[m]>heh. The DEC SRC archives are such a gold mine. And those reports are getting increasingly hard to find. I stick them in the wayback machine whenever I read one. <dckc[m]>so nobody here can help with admin of the ocapn github repo? We're in the T-24hrs of meeting prep. It would be nice to get low-latency responses. <tsyesika>I'm in a meeting atm, will answer in 20 mins <ocdtrekkie>I don't mind Feb 21. I usually just duck out for lunch for OCapN meetings, they are always somewhere around lunch time for me and my lunch time is flexible. <Zarutian_iPad>had to ask due to linguistic confusion arising from diffrent lingua traditions <ocdtrekkie>I also don't consider myself crucial attendance. Ian knows more than me about everything capnp and he is usually there. <Zarutian_iPad>re timing of meetings, usually there is nothing good on the telly during the evening hence I do not mind <dckc[m]>maybe stick a 👍️reaction on my Feb 21 proposal in github? <dckc[m]>(enough meeting prep for now; demoting this window...) <Zarutian_iPad>ACTION smashes that thumbs up like a þútúpuáhrifavaldur from early Ought <tsyesika>let me have a quick look before I dissapear for the evening <tsyesika>okay I'm not sure if it's possible to let anyone assign themselves to stuff <tsyesika>I guess I could add people who are interested <ocdtrekkie>I think there is an issue triage role you can grant people where they can do issue management tasks but not merging or changing repo settings. <isd>I will be traveling the 20th & 21st, and won't be able to make it <isd>The rest of that week I'd be available <jfred>ocdtrekkie: I've had similar thoughts about Spritely apps using Sandstorm grains as a well-known connection point. It seems well-positioned to do that <jfred>And I just had a thought... would be neat if you could configure your Spritely "agency" (when that's a thing) with a capability to your Sandstorm server that let it send an arbitrary bundle of code to run in a new grain <isd>What does the term "agency" refer to in the context of spritely? <jfred>I think I'm remembering the name of that concept right... believe it's only come up in one talk, let me grab a link <isd>Ok, I'll have to watch that. <jfred>I think roughly equivalent to a browser as "user agent" in that it's the runtime environment for Spritely apps, but with more built in social stuff (petname system, etc) <isd>As a side note, I really do want to challenge the spritely folks to articulate "why not capnp?" and "why not agoric?"; I can think of some coherent arguments of varying strengths, but it seems very sad to to have 3 protocols when you could have only had 2 with no stated rationale for the third. It ends up looking very NIH. <isd>I'm not sure I think a 3rd protocol is the wrong call even, but I want to make sure this is actually a considered decision, rather than just a gut call. <jfred>In the talk it's envisioned as being P2P, but I feel like there might be some cases where it might be helpful for an app to be able to say "run this bit over there, I know it's more reliably online than this device is" <isd>Yeah, I think there's value in having an always-on device; cutting out servers has its advantages, but following that too religiously can lead you to horribly inefficient blockchain solutions that don't really make any sense. <isd>Also being able to just give someone a sharing link to something is huge for reducing friction <ocdtrekkie>I mean, also, not needing a server is nice if you don't have a server. Not using a server if you have one often feels silly. <RandyFarmer[m]>... I'm not meaning to be snarky by asking this: What defines a "server" these days? What are it's attributes/capabilities? A lot of people mean a lot of different things by "server." <tsyesika>dckc: I've added you as a contributor so hopefully you'll be able to assign yourself to issues and such <tsyesika>sorry for the delay, I've been quite busy today <dckc[m]>I can imagine. Are you the only one with the power to grant contributor access, Jessica ? (I suppose it's poor opsec for me to ask here.) <isd>Good question. To me: a computer is a server if: <isd>1. It is always on & available, except possibly for maintenance and/or unplanned outages. <isd>2. The user interacts with it over the network via a separate device <jfred> RandyFarmer[m]: I thought that might come up haha. You could say the use of an always-on node is still P2P, just with somewhat heterogeneous peers <dckc[m]>I can imagine a ritual where (1) folks agree to the charter and (2) they're granted collaborator access <dckc[m]>operational definition of "server": accepts responsibility for NAT traversal :) <isd>Not sure I see the utility of that definition... <isd>Anyway, the above is what I'm getting at when I say it. <jfred>I still dream of ubiquitous IPv6 and an end to NATs. A foolish dream, perhaps :P <dckc[m]>It's perhaps a corollary or a deployment constraint. Anything putting itself in the position of a server ("always on and available") must, practically, accept that its clients may be behind one or more NATs. <dckc[m]>I have come to the conclusion that ubiquitous IPv6 is not a reasonable goal. We have cells and organs and individuals and groups and so on, with connective tissue at each level, not one "bus" everywhere. <ocdtrekkie>My ISP doesn't even support IPv6, and it's a major US carrier, so we have a ways to go. <jfred>dckc[m]: Oh, sure. But it sure would make lots of things easier <ocdtrekkie>But yeah, a server to me is a always on system I can reach to from any of my devices. I think like, it's great any PC can run on IRC client, but if, say, I have the option to host a bouncer on my server and connect to that, running an IRC client directly on my phone starts to seem like a really dumb thing to do. (Obviously today I cheat by just using matrix.org) <isd>(matrix.org being a server) <ocdtrekkie>As a network security person, I really enjoy the somewhat incidental security benefits of NAT. A lot of things are accidentally more secure than they would be otherwise because things just don't know how to route traffic to those things. <isd>Yeah, I think ocap people should appreciate that things just not being addressable can sometimes be Good, Actually. <jfred>Hm, I'd never made that connection before. Have to think on that <ocdtrekkie>I am a bit confused by the statements re: OCapN in the blog, considering we are very early in discussion of defining OCapN as a standard. <RandyFarmer[m]>You're right, it's a problem that the term exists (and may be a bit ambiguous) until it's standardized - though this particular use goes back a few years when Christine created the repository... <RandyFarmer[m]>Rest assured that we will comply with the standard as it devlops. :-) <ocdtrekkie>Perhaps something akin to how Google refers to their original QUIC implementation as "gQUIC" as opposed to standard QUIC, it might help to differentiate with some modifier until they coalesce? <isd>Yeah, I think it's ok as long as we don't end up with pre-standard versions of ocapn in use in the wild after the standard is settled <isd>Though we could use something like "goblins-captp" <isd>to refer to "whatever goblins is using" <RandyFarmer[m]>Everyone who cares is part of the discussions at this point. We can sort this as we go, I think. <isd>Yeah, I'm not too worried. <ocdtrekkie>I just imagine it will inevitably cause confusion, even internal to Spritely projects, if some versions of Goblins support pre standard OCapN, and some versions of Goblins support standard OCapN in the future, and both are referred to as "OCapN" in docs/blogs/sites/etc. <ocdtrekkie>Well, I mean like, PoE has been a standard for how many decades, and pre-standard PoE implementations still appear in active use (my home firewall still supports one!). Software thankfully deprecates a bit faster than hardware, but you may have Goblins implementations in the wild which correspond to different versions of things, especially as more people build on it. <RandyFarmer[m]>It's OK. After all, I was one of the first E programmers (or should I say Original-E)? :-) Goblins isn't even 1.0 yet. We're ok for a little while. <isd>I think we can address that if/when somebody outside the developers of the reference implementations shows up and says they want to implement. <isd>...and isn't satisfied with me telling them there's a Rust implementation of Cap'n Proto they should look at :P <isd>Why is it always Rust? <ocdtrekkie>I think most software communities acknowledge the concept that rewriting something is a bad idea. ;) And the Rust community does not seem to. <dckc[m]>I was somewhat surprised to read that rewriting whole systems every few years is the expected norm at Google. (IOU the source; it was from some Google eng doc.) <ocdtrekkie>That's probably a reasonable position if you are all in on microservices, where rewriting any given piece has a relatively confined scope. <ocdtrekkie>And also you have over a hundred thousand employees you need to keep busy doing things so they don't build competitors. <Zarutian_iPad>oh, kind of atvinnubótavinna (which is basically work to keep folks occupied) <isd>"busy work" in English. I'm mostly joking around; I'm sure Google has plenty of things that it actually needs done. <isd>sapping folks' energy to challenge them is a side benefit :P <tsyesika>Zarutian_iPad: looks like it should be something to do with recycling <isd>I feel like Google's internal engineering practices end up shaping a culture that is really bad at making dev tools <isd>...for folks outside the company anyway