08:31:53 <dan-shearer[m]> #startmeeting 
08:31:53 <lumosql-meetbot> dan-shearer[m]: Meeting started at 2022-07-22T08:31+0000
08:31:54 <lumosql-meetbot> dan-shearer[m]: Current chairs: dan-shearer[m]
08:31:55 <lumosql-meetbot> dan-shearer[m]: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
08:31:56 <lumosql-meetbot> dan-shearer[m]: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
08:31:57 <lumosql-meetbot> dan-shearer[m]: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
08:32:20 <dan-shearer[m]> #meetingname Weekly Update
08:32:20 <lumosql-meetbot> dan-shearer[m]: Meeting name set to: Weekly Update
08:32:21 <Labhraich> #here Claudio
08:32:28 <dan-shearer[m]> #here Dan
08:32:28 <rubdos[m]> #here Ruben
08:33:05 <dan-shearer[m]> #topic Admin Items
08:33:18 <dan-shearer[m]> #info No Björn or Gabby today
08:33:41 <dan-shearer[m]> #info Dan just back from extended break
08:34:16 <dan-shearer[m]> Labhraich and Ruben De Smet , shall we just get into your bits? On reflection I notice I have a few updates too but I have to get my thoughts in order.
08:34:43 <rubdos[m]> Sure
08:34:55 <dan-shearer[m]> ... and we call your bits "ABE System" is that correct?
08:35:01 <rubdos[m]> SQL-PE? :-)
08:35:04 <dan-shearer[m]> No, not quite
08:35:16 <dan-shearer[m]> #topic SQL-PE
08:35:47 <Labhraich> I don't have much to say but I'll wait for Ruben to say his bit first
08:35:49 <rubdos[m]> #info There's now a basic authentication system in the PoC implementation.
08:36:30 <rubdos[m]> #info I won't be working on SQL-PE probably until half of August, but after that it should be my full-time work.
08:36:50 <rubdos[m]> The goal is to have SQL-PE as the "last part" of my PhD work before I start writing my PhD, so it'll have to be in there :-)
08:37:13 <rubdos[m]> Until 1st of August I'll be working on a paper that needs to be resubmitted, and after that I'm taking some weeks of.
08:37:38 <rubdos[m]> #info Martina is probably coming to Belgium somewhere in September to work together on the ABE part.
08:37:48 <rubdos[m]> I think that's most of it.
08:37:53 <dan-shearer[m]> Do we have a URL for the PoC?
08:38:04 <dan-shearer[m]> *PoC so far
08:38:14 <rubdos[m]> We do, let me have a look
08:38:26 <dan-shearer[m]> Can you #link <explanation>
08:39:14 <rubdos[m]> #link https://gitlab.com/etrovub/smartnets/sql-pe The PoC of the SQL-PE library, including a directory for currently non-existing bindings to LumoSQL
08:39:46 <rubdos[m]> Oh that's still locked behind a private repo
08:39:50 <rubdos[m]> let me make it public really quick
08:40:28 <rubdos[m]> There we go.
08:41:48 <dan-shearer[m]> Great! there is some chat to be had about where exactly those non-existing bindings should be implemented.
08:42:27 <rubdos[m]> Given that Labhraich is building an extension API, it'll be modular and separate anyway. I think Labhraich and me have quite a good idea on where everything can live :-)
08:42:43 <rubdos[m]> But there's certainly more stuff to be discussed there.
08:43:30 <dan-shearer[m]> But I can imagine that if, by the middle of August, we have the ability to say "GRANT $something to $someone" and it calls a Labhraich API which then prints a text line that says "Just called PoC function X" then that would be perfect.
08:43:51 <rubdos[m]> Oh it'll do more than that by the end of August, I hope.
08:43:57 <Labhraich> Yes, we have quite a good idea.  I haven't quite typed it all but I'm making the draft document a bit clearer and will circulate it this weekend for more comments.  After that, it'll hopefully be time to put it in fossil
08:44:02 <rubdos[m]> It's mostly the CREATE ROLE kinda code at the moment.
08:44:38 <rubdos[m]> Gitlab/ETROVUB/Smartnets is probably also no the final place for the code to live, but given it's a PoC at the moment, I don't think anyone should care too much about that.
08:45:40 <dan-shearer[m]> I think the PoC also needs to be standalone, but that was the plan from the beginning I think. So that curious compsci people can try some operations and see what happens.
08:45:55 <dan-shearer[m]> Ok that's good.
08:46:04 <dan-shearer[m]> So, is the following statement correct.
08:46:24 <dan-shearer[m]> "There is currently nothing much that can be updated in the draft RFC until mid-August"
08:46:53 <dan-shearer[m]> Because Labhraich's stuff is mostly too far down to go in the RFC.
08:47:40 <Labhraich> Correct. My stuff is about how we implement things at the lower level, and is something we don't want to dictate in an RFC
08:47:49 <dan-shearer[m]> I think the RFC is a very effective communication tool, or will be, as well as keeping us focussed on the idea of interoperability of the end objects handled by SQL-PE.
08:48:37 <Labhraich> There are RFCs which go and dictate things at the micro-detail level and they actually make it harder to have interoperting things - any system where that micro-detail doesn't fit for example won't be able to use the thing
08:48:55 <rubdos[m]> I think the RFC will be mostly applicable once we start defining the Lumion object type
08:49:28 <rubdos[m]> Conceptually, there's probably something to be written down already, but practically, I'd wait a bit longer.
08:50:36 <dan-shearer[m]> Ok then great. I am aware that there may be scope for other RFCs, but it would be easy to get RFC fatigue :-)
08:51:35 <dan-shearer[m]> #action Dan to make minor updates to the RFC (eg slightly more correct terminology such as Predicate Encyption)
08:52:34 <dan-shearer[m]> So in summary Ruben, you don't expect there to be more commits to the Smartnets tree until mid-August, and the Smartnets tree already defines what Labhraich needs to know?
08:53:58 <rubdos[m]> Yes and no. But Labhraich 's work and mine kind of grow to each other. His first draft proposal for the API was very good and close enough for there to be work for the both of us.
08:54:03 <rubdos[m]> Work enough until September probably :)
08:54:35 <Labhraich> Ah well, but don't tell me that or I'll slack until end of August :-)
08:54:56 <rubdos[m]> There's work enough to fill the whole time from now until August! :P
08:55:12 <rubdos[m]> By end-of-august, I should be able to start linking to your API! :D
08:55:49 <rubdos[m]> Your work should be finished by then !
08:56:07 <dan-shearer[m]> Sounds like the perfect moment to introduce a new topic, "API business", unless there is more Ruben?
08:56:30 <rubdos[m]> Nope
08:56:32 <rubdos[m]> </ruben>
08:56:48 <dan-shearer[m]> #topic LumoSQL APIs
08:57:34 <Labhraich> Not much to report from me.  I've had difficulty concentrating (as I said in the last meeting) and so days seem to finish before I have enough coffee to start
08:57:51 <Labhraich> I've been going through the draft slowly and trying to make it clearer
08:58:12 <Labhraich> Some of the comments were actually already answered - but the document was a bit obscure and the answeronly made sense to me
08:58:22 <Labhraich> I'm hoping to have a new draft to circulate this weekend
08:58:29 <Labhraich> That's actually all
08:59:23 <Labhraich> So if somebody were to tell me that Ruben needs it all by next week I might concentrate better :-)   I haven't read the bit mentioning September
08:59:28 <dan-shearer[m]> #info Labhraich is working on a new draft API document to commit to Fossil in the fairly near future
08:59:50 <rubdos[m]> Well, I'll need the draft by mid next week if you want a review :'-)
09:00:01 <dan-shearer[m]> There must be a Ruben review.
09:00:01 <Labhraich> #action Labhraich to finish and circulate new draft, with the aim of committing to fossil next week or so
09:00:55 <dan-shearer[m]> Labhraich: are you up for trying to have a daily phonecall? Even if it is just two minutes sometimes? You can see I am worried about these sorts of non-technical head issues too.
09:01:16 <rubdos[m]> Shall we try to close the SQL-PE LumoSQL gap by let's say 21st of August? Then you should be able to expose the necessary API's for CREATE ROLE and I should be able to implement them from a .so dynamic lib
09:01:45 <dan-shearer[m]> Whatever phone you used to call me this morning worked fine, so I assume you have your VoIP going now, or something else.
09:02:07 <Labhraich> I've been doing lots of non-technical, sweaty stuff.  Like gardening.  I've also installed a few rainwater collecting buckets (300 litre each) because it looks like this sort of things will be more and more necessary (I still have 100 litres left from last rain!)
09:02:30 <Labhraich> Yes, I did not call from Edinburgh, no matter what the caller ID might have claimed
09:02:33 <dan-shearer[m]> approves. Very Australian.
09:03:22 <Labhraich> So anyway, that's all from me on API.
09:03:48 <Labhraich> I did make some changes to not-forking to help packagers (mostly as a way to convince myself that I can concentrate on a small technical task)
09:04:09 <Labhraich> (these changes are all in fossil)
09:04:15 <dan-shearer[m]> Yesterday, without turning on networking (because I didn't want anything inbound) I had a look at the SQL parser.
09:05:20 <dan-shearer[m]> My goal is to write a document that says "Here is how you add a command called SMILE, with qualifiers such as AT CROCODILE"
09:05:58 <dan-shearer[m]> Such a general document can be reviewed by sqlite.org without any reference to LumoSQL-ish-ness.
09:06:04 <Labhraich> That would be useful, and we'll need that... I am concentrating on PRAGMAs and SQL functions but some of this stuff can probably do with some extra syntactic sugar
09:06:52 <Labhraich> (and of course C functions to do the actual work, so that if there's a different interface it just needs to call the C functions)
09:07:17 <dan-shearer[m]> Well doesn't CREATE ROLE naturally happen with SQL sugar?
09:08:02 <Labhraich> It's presumably an INSERT into a hidden table which we do via the metadata API...
09:08:31 <dan-shearer[m]> Yes I suppose something like that.
09:09:16 <Labhraich> The only question (which comes from discussion of the first API draft) is about inserting data
09:09:34 <Labhraich> I wasn't going to provide an interface for that, since SQLite already provides a fine interface to this sort of things
09:10:01 <Labhraich> But if I have some data + some metadata it means calling SQLite to insert the data, and then arrange for the metadata to be provided "when SQLite asks"
09:10:12 <dan-shearer[m]> There are something like 40 million (!!!!!) mobile app developers in the world, of whom an unknown but large number use SQLite via SQL. Every networked SQL database has CREATE ROLE and GRANT etc, so, that's how we join the dot.s
09:10:21 <Labhraich> So there could be a simpler interface at the API level to just pass both and not care about callbacks
09:10:47 <Labhraich> (it needs to be done this way, otherwise the SQLite changes will be massive, to carry all the metadata around until it's needed)
09:12:05 <Labhraich> So anyway, lots of untyped thinking which will need to go into the next draft API document
09:12:43 <Labhraich> untyoped in the sense that it has not yet been written into the draft document, that is, not untyped in the sense that it doesn't have a type or is not type safe :-)
09:13:23 <dan-shearer[m]> Yes.
09:13:36 <dan-shearer[m]> In the first sense, Ruben and i are saying it needs to be strictly typed.
09:13:43 <Labhraich> #info Labhraich keeps IRC logs of this channel, and they can be made available on request to people who want to be reminded of past discussion
09:14:44 <dan-shearer[m]> That's helpful.
09:15:05 <dan-shearer[m]> Ok anything more?
09:15:15 <Labhraich> I've been reading them the last few days precisely because the API discussion happened in part here
09:15:19 <Labhraich> No, nothing more
09:15:27 <dan-shearer[m]> I am extremely aware that there are some dates listed above, quite important ones.
09:16:03 <dan-shearer[m]> So I will go through and put them in one place so its all clear.
09:16:30 <dan-shearer[m]> Because, Björn is going to say things like "so when will there be something a person can actually test?"
09:16:57 <dan-shearer[m]> This is a large queue of things waiting on that.
09:16:58 <dan-shearer[m]> *There is
09:17:15 <dan-shearer[m]> And I think we now have a reasonable expectation of when that might be.
09:18:17 <Labhraich> I was going to rewrite the PoC rowsum code to use the new API as soon as I have something stable - this will at least provide a test of my part of this
09:19:58 <dan-shearer[m]> Ok
09:20:08 <dan-shearer[m]> so I think there are two levels of demo
09:21:01 <dan-shearer[m]> 1. type some commands (#pragmas and/or SQL) which cause encrypted rows to be written in response to standard SQL
09:21:51 <dan-shearer[m]> There are various things we can do with that. Like showing it is a normal row, you just can't read it except for the GUID. We can write a human-readable script of things to try.
09:22:13 <Labhraich> Well, we can read it, but it'll be an untranslatable blob
09:22:48 <dan-shearer[m]> 2. An actual app, presumably the password safe, written in some language linked to libsqlite, which is actually liblumosql but we haven't worked on making that happen yet.
09:23:20 <dan-shearer[m]> *libsqlite3 of course
09:23:31 <Labhraich> I can do 1, but 2 is best left to somebody else
09:23:40 <dan-shearer[m]> By definition, yes
09:23:56 <dan-shearer[m]> And now you need to do some strict typing!
09:24:27 <Labhraich> Actually now I need to make coffee!
09:25:08 <dan-shearer[m]> Hmmm - in some ways, having demo 2 exist as soon as we know the C or SQL interface would be very cool even when none of the bindings and other code is in place. Because then it would keep failing until magically springing into life.
09:25:30 <dan-shearer[m]> Ok
09:25:39 <dan-shearer[m]> It's been a pleasure. This is actually happening, team!
09:25:44 <dan-shearer[m]> end meeting?
09:25:56 <Labhraich> Well, 2 needs to be something which calls (the SQL in) 1, and has some form of user interface (the latter being the bit which I am definitely not doing)
09:26:25 <Labhraich> So if I get 1. done that'll make it easy for a person who can do user interfaces to join the dots
09:26:30 <dan-shearer[m]> Yes. But we both like writing the tests first, and this is kind of that.
09:26:47 <dan-shearer[m]> That's all.
09:27:58 <dan-shearer[m]> #endmeeting 
09:28:17 <Labhraich> Yes I prefer to have the tests first.  So for 1, I'll write the SQL/PRAGMAs and then do whatever is needed so they stop producing errors
09:28:35 <dan-shearer[m]> Hum
09:28:43 <dan-shearer[m]> I don't see much endmeeting happening.
09:28:50 <Labhraich> meetbot doesn't seem to be awake
09:29:16 <dan-shearer[m]> Thankfully, if something has gone wrong with the meetbot, everything has been written to a JSON file in the new version and can be regenerated.
09:29:31 <dan-shearer[m]> #endmeeting 
09:29:38 <dan-shearer[m]> I'll kick it
09:31:31 <dan-shearer[m]> oops
09:31:33 <dan-shearer[m]> out of space
09:31:39 <dan-shearer[m]> hopefully that's all
10:00:46 <dan-shearer[m]> #endmeeting