IRC channel logs

<amz3`>so my js-closure function doesn't properly capture the closure

<amz3`>that the last bug I need to tackle before being able to run my framework

<amz3`>and that is a success!

<amz3`>I found the bug, fixed and my framework works

<amz3`>\\o/

<amz3`>and it's not slow, yet ;)

<amz3`>ouf!

<amz3`>which means I will have a nice week end

<happy_gnu[m]>amz3`: great :)

<amz3`>the code is here https://gitlab.com/amirouche/guile/tree/compile-to-js-2017

<ijp>amz3`: yeah, that one is easy done

<amz3`>indeed, it was not hard if i succeed

<amz3`>still a win!

<dustyweb>beep hello

<civodul>hello!

<dustyweb>I need to implement HTTP Signatures for Guile

<dustyweb>because it turns out!

<dustyweb>this is being implemented by all ActivityPub implementations in practice

<dustyweb>this is good because HTTP Signatures is a solid spec!

<dustyweb>the bad news is I can't use Guile's built-in web server

<dustyweb>reason being that the way we handle headers is "nice" in that everything's ported to actual types you can mess with

<dustyweb>however, with http signatures when we read a request we're going to have to quasi-canonicalize it

<dustyweb>and unforutnately

<dustyweb>that involves preserving the whitespace etc of headers

<dustyweb>and also the ordering!

<dustyweb>ordering, I think we can do that, but whitespace, not the case.

<dustyweb>so I'm thinking of what I have to do, and best I can tell I should do the following:

<dustyweb>read the headers for canonicalization while also writing the original contents out to a string port

<dustyweb>and *then* pass the string port's contents over to guile's normal headers parsing code

<dustyweb>ramble ramble ramble

<dustyweb>anyway! that's what's up with me

<civodul>dustyweb: oh so these are signatures computed over the set of HTTP headers?

<civodul>we had a similar "problem" for narinfo signatures FWIW, where we have to keep the exact initial narinfo representation (order, whitespace, etc.) to be able to verify the signature

<dustyweb>civodul: signtures of both headers and body, but headers need to be able to be "normalized", yeah

<civodul>so the signature is over normalized headers, or over the headers as-is?

<dustyweb>semi-normalized, but now I'm confusing myself!

<dustyweb>normalized at least in terms of "they are sorted"

<dustyweb>at the very least we'll hit the problem that this needs to be able to normalize headers guile doesn't "know about"

<civodul>if it's "normalized" it's less bad than if it needs to be as-is

<civodul>perhaps Guile could do it

<civodul>after all it already does a pass of "normalization"

<dustyweb>yeah maybe

<dustyweb>civodul: though would still need to handle terms that Guile currently "drops"

<civodul>hmm yeah

<daviid>amz3: you could ask the libgit2 team to add en entry for guile-git (actually send a patch ...)

<amz3`>daviid: a patch about what?

<amz3`>daviid: an entry in guile projects?

<daviid>about their front page and bindings page ...

<amz3`>daviid: oh

<daviid>so guile-git appeas on the front page, next to chicken-git :) ...

<amz3`>daviid: yeah, but it's not complete yet

<amz3`>daviid: I mean it's far from complete even if useable

<amz3`>daviid: sure I will submit a PR for that once I find it good enough

<amz3`>I was supposed to work on hat this week end

<daviid>not usable? I thought guix was using it already

<amz3`>yes, it's useable but incomplete

<amz3`>but since guile-js is working... I think I will give guile-js a go ;)

<daviid>ah ok

IRC channel logs

2017-09-08.log