01:47 <ill_logic> Ian Denhardt: Did you push it yet?

01:47 <ill_logic> nm was looking in the wrong place

01:47 <ill_logic> found it

06:59 <isd> So, that janky app we used now includes an in-browser vnc client.

11:00 <CcxWrk> isd: FWIW I kind of have a federated replacement for Keybase underway. In the planning stages that is. Only the parts that pertain to transparent verifiable key updates though, so you can have safe key rollover (unlike PGP).

11:00 <CcxWrk> I think I've mentioned it on this channel before.

15:34 <isd> CcxWrk: maybe you have, but I don't remember it. Do you have design docs or anything somewhere? I'm curious to read about your approach.

15:43 <CcxWrk> isd: Not yet. The concept is fairly simple on the outer level: identity servers would maintain Certificate-Transparency-style record of modifications to keyspace of each identity. In that sense it works like PGP keyserver, but only allows modification statements signed by the proper identity keys. And the server will be unable to selectively lie about which keys are being considered trusted (without being

15:43 <CcxWrk> caught) so users can be made aware of key compromise. This requires auditors running on the data, but given I consider this for XMPP/OMEMO (and eventually MLS) you already have federated network with cross-server interaction on user basis so servers auditing each other shouldn't be issue.

15:46 <CcxWrk> The hard part is I decided to make the language of identity updates as flexible as possible. So now I'm developing what possibly could be capability-secure language for transparent data structures. So you could have lot of different keys that allow you transform the data in arbitrary attenuated ways.

15:48 <CcxWrk> The idea to do this came when I was tackling a different issue: lack of good issue tracker. So I'm now prototyping some code now on that use-case and hope it will scale up to the identity server goals.

15:50 <CcxWrk> Both are public data with necessary access/authority controls that ought to be reproducible on a local copy. The only thing you really need a central point is for serializing the operations on it (and sometimes partial order is fine, but not always).

16:01 <CcxWrk> isd: You may also be interested in: https://blog.okturtles.org/2017/02/coniks-vs-key-transparency-vs-certificate-transparency-vs-blockchains/

16:05 <crab> what does "transform the data in arbitrary attenuated ways" mean? specifically, the "attenuated" part?

16:06 <simpson> In general, an attenuation is when we take some capability and reduce what it can do. This is usually done in code with a wrapper object.

16:07 <simpson> Here's an example from some recent Monte code. The map `m` is attenuated to only be able to do lookups with a fixed default; e.g. the ability to enumerate the map's keys has been attenuated away. https://github.com/monte-language/typhon/blob/master/mast/fun/cantor.mt#L11-L12

16:07 <CcxWrk> crab: What simpson said, for more thorough description you can scroll to "Capability patterns" in http://habitatchronicles.com/2017/05/what-are-capabilities/

16:12 <CcxWrk> simpson: FTR so far I'm simulating objects/recipient-only actors using Datalog and Event Calculus-style encoding. This doesn't allow me to push new code though and I'll probably be trying to invent linear logic flavour of Datalog.

16:13 <simpson> CcxWrk: Sure. Objects end up being very natural if we strip down most of the decorations; any effect transformer will work, as long as they can be composed.

16:13 <simpson> Like, an object is a behavior which naturally transforms some context according to received messages. All you have to do is be natural over *any* context.

16:20 <CcxWrk> I'm not even sure whether to call it object at this point, it has data and reacts to messages, which is far from any common OOP definition. But it's not like I have a better term for it.

16:31 <CcxWrk> Hrm, so now thinking I guess right now I have "classful" style where the methods are pre-set and I want to allow changing them while having good encapsulation. Suddenly making this fuller OO with several objects / stateful message transformers is tempting.

16:35 <CcxWrk> I really didn't envision myself building OODB when I started this and tbf I'm not sure if I like that direction. But so far I don't see anything simpler to do here.

16:39 <simpson> It can get much more complex, if you need more types to get more structure. https://hackage.haskell.org/package/objective is my favorite recipe, although it's so hard to actually wield in Haskell.

16:42 <CcxWrk> Yeah, I don't think I'll be thinking about types until after I have useful working prototype. And then only to see if there is something that would match the model well rather than vice versa.