Hello Guile users, I’m writing a Solid server in guile: https://disfluid.planete-kraus.eu/ https://labo.planete-kraus.eu/webid-oidc.git/ The main point of Solid [1] is to separate the web applications from the data they use in an interoperable way. It’s in the spirit of Activitypub, but closer to the current architecture of the web. So, whenever you see "Log in with <data silo>", you could easily demand that the application let you log in with your identity on your Solid pod. If that takes off, we’ll be able to run any competing web application with any data storage ("pod"), because the communication is interoperable and the vocabulary used is public. Which means that we will be able to easily replace proprietary program with free programs! The best thing is, we won’t even need to develop for a web browser. That’s a cool solution to the JavaScript trap. Now, we need to make sure that there is a freedom-respecting way to develop applications. This is why I’m writing this project. With a clear focus on user freedom, we will maximize our chances to avoid the future JS traps. In this regard, disfluid is not Solid. [1]: https://solidproject.org/
[-- Attachment #1.1.1: Type: text/plain, Size: 343 bytes --] > Hello Guile users, > > I’m writing a Solid server in guile: > > https://disfluid.planete-kraus.eu/ > https://labo.planete-kraus.eu/webid-oidc.git/ > > The main point of Solid [1] is to separate the web applications from > the data they use in an interoperable way. Yo ! Love it ! Wish you to make it ! Cheers, Jérémy [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 2515 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 665 bytes --]
Looks really neat!
I'm still not familiar with Pod.
Is it possible to cooperate with a modern web framework? It seems it
doesn't require JS and browser, so I don't know if http can still work as
usual.
Best regards.
On Fri, Jul 30, 2021, 19:21 Vivien Kraus via General Guile related
discussions <guile-user@gnu.org> wrote:
> Hello Guile users,
>
> I’m writing a Solid server in guile:
>
> https://disfluid.planete-kraus.eu/
> https://labo.planete-kraus.eu/webid-oidc.git/
>
> The main point of Solid [1] is to separate the web applications from
> the data they use in an interoperable way.
>
> It’s in the spirit of Activitypub, but closer to the current
> architecture of the web. So, whenever you see "Log in with <data
> silo>", you could easily demand that the application let you log in
> with your identity on your Solid pod.
>
> If that takes off, we’ll be able to run any competing web application
> with any data storage ("pod"), because the communication is
> interoperable and the vocabulary used is public. Which means that we
> will be able to easily replace proprietary program with free programs!
> The best thing is, we won’t even need to develop for a web browser.
> That’s a cool solution to the JavaScript trap.
>
> Now, we need to make sure that there is a freedom-respecting way to
> develop applications. This is why I’m writing this project. With a
> clear focus on user freedom, we will maximize our chances to avoid the
> future JS traps. In this regard, disfluid is not Solid.
>
> [1]: https://solidproject.org/
>
>
>
Hello, Le samedi 31 juillet 2021 à 14:14 +0800, Nala Ginrut a écrit : > Is it possible to cooperate with a modern web framework? It seems it > doesn't require JS and browser, so I don't know if http can still > work as usual. It is not tied to a particular framework, the specification is based on HTTP. Guile has by default almost everything we need, https://www.gnu.org/software/guile/manual/guile.html#Web The missing parts are a couple of HTTP headers that are simple to handle. However, I’d like to have uri-decode handle unicode characters, because most URIs nowadays are IRIs and they have unescaped unicode characters. That’s why I sent this patch: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49085
[-- Attachment #1: Type: text/plain, Size: 836 bytes --] Vivien Kraus via General Guile related discussions <guile-user@gnu.org> writes: > It is not tied to a particular framework, the specification is based on > HTTP. Guile has by default almost everything we need, > https://www.gnu.org/software/guile/manual/guile.html#Web > > The missing parts are a couple of HTTP headers that are simple to > handle. Maybe some hacks I needed for my (unfinished) implementation of the downloadmesh can be useful to you: https://hg.sr.ht/~arnebab/wispserve/browse/wispserve/serve.w custom headers: https://hg.sr.ht/~arnebab/wispserve/browse/wispserve/serve.w?rev=ab4c95b7a9ff#L115 handle multi-part uploads: https://hg.sr.ht/~arnebab/wispserve/browse/wispserve/serve.w?rev=ab4c95b7a9ff#L627 Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
Hello,
Le samedi 31 juillet 2021 à 10:58 +0200, Dr. Arne Babenhauserheide a
écrit :
> Maybe some hacks I needed for my (unfinished) implementation of the
> downloadmesh can be useful to you:
The "missing headers" were missing in Guile, but I added them for my
server (I did it with declare-header!, whereas you used declare-opaque-
header!, but we had the same idea).
The lack of unicode support is more of a concern for me, and something
has to happen on Guile’s side. This is why I submitted a patch.
Hi Vivien, This sounds great even though I don't fully understand it :-) but I'm starting to read a little bit about Solid (and Disfluid). While I was reading I found this: """ Both the header and the payload use the JSON representation from srfi-180: objects are alists of symbols to values, arrays are vectors. It is unfortunate that guile-json has a slightly different representation, where alist keys are strings, but we hope that in the future SRFI-180 will be more closely respected. """ Unfortunately guile-json doesn't follow srfi-180 api (it was created much sooner), but regarding alists' keys it can support both symbols and strings. So you can do (scm->json '((foo . "bar"))) or (scm->json '(("foo" . "bar"))) and both would work the same. By the way, a long time ago I also worked on guile-jwt ( https://github.com/aconchillo/guile-jwt) which is SUPER basic compared to what you've done. I was planning to add JWK support at some point. I'm wondering if we could take your code and merge it into guile-jwt so other projects can use it. What do you think? Right now I don't have much time but if you say it's fine I could work on it whenever I'm free. Thank you! Aleix On Fri, Jul 30, 2021 at 4:21 AM Vivien Kraus via General Guile related discussions <guile-user@gnu.org> wrote: > > Hello Guile users, > > I’m writing a Solid server in guile: > > https://disfluid.planete-kraus.eu/ > https://labo.planete-kraus.eu/webid-oidc.git/ > > The main point of Solid [1] is to separate the web applications from > the data they use in an interoperable way. > > It’s in the spirit of Activitypub, but closer to the current > architecture of the web. So, whenever you see "Log in with <data > silo>", you could easily demand that the application let you log in > with your identity on your Solid pod. > > If that takes off, we’ll be able to run any competing web application > with any data storage ("pod"), because the communication is > interoperable and the vocabulary used is public. Which means that we > will be able to easily replace proprietary program with free programs! > The best thing is, we won’t even need to develop for a web browser. > That’s a cool solution to the JavaScript trap. > > Now, we need to make sure that there is a freedom-respecting way to > develop applications. This is why I’m writing this project. With a > clear focus on user freedom, we will maximize our chances to avoid the > future JS traps. In this regard, disfluid is not Solid. > > [1]: https://solidproject.org/ >
Hello Aleix ! Le dimanche 01 août 2021 à 23:27 -0700, Aleix Conchillo Flaqué a écrit : > Unfortunately guile-json doesn't follow srfi-180 api (it was created > much sooner), but regarding alists' keys it can support both symbols > and strings. So you can do (scm->json '((foo . "bar"))) or (scm->json > '(("foo" . "bar"))) and both would work the same. Exactly! The problem is in the other way around, json->scm. By default, I get stringly-keyed objects, so I add another pass to convert them to symbolicly-keyed objects. > By the way, a long time ago I also worked on guile-jwt ( > https://github.com/aconchillo/guile-jwt) which is SUPER basic > compared to what you've done. I was planning to add JWK support at > some point. I'm wondering if we could take your code and merge it > into guile-jwt so other projects can use it. What do you think? Right > now I don't have much time but if you say it's fine I could work on > it whenever I'm free. That would be awesome, but working with C bindings is a pain with guile. If you inherit all the JWS and JWK code, I still need to keep them around for things like hashing the URIs for the cache and resource server and generating random numbers. The clever thing to do would be to switch to guile-gcrypt first (so that I don’t have any more C) and then move the code to guile-jwt (we can still change the API if you prefer another one, I don’t have a 1.0 release yet). Since that code will most likely be run on web servers, have you considered releasing it under the AGPL? Best regards, Vivien
On Mon, Aug 2, 2021 at 1:20 AM Vivien Kraus <vivien@planete-kraus.eu> wrote: > Hello Aleix ! > > Hi! > Le dimanche 01 août 2021 à 23:27 -0700, Aleix Conchillo Flaqué a > écrit : > > Unfortunately guile-json doesn't follow srfi-180 api (it was created > > much sooner), but regarding alists' keys it can support both symbols > > and strings. So you can do (scm->json '((foo . "bar"))) or (scm->json > > '(("foo" . "bar"))) and both would work the same. > > Exactly! The problem is in the other way around, json->scm. By default, > I get stringly-keyed objects, so I add another pass to convert them to > symbolicly-keyed objects. > > Oh, duh! I see what you mean now. I'm on vacation and it seems my brain is too :-) (it might always be...). Maybe I could add a flag to json->scm to choose between the two. > By the way, a long time ago I also worked on guile-jwt ( > > https://github.com/aconchillo/guile-jwt) which is SUPER basic > > compared to what you've done. I was planning to add JWK support at > > some point. I'm wondering if we could take your code and merge it > > into guile-jwt so other projects can use it. What do you think? Right > > now I don't have much time but if you say it's fine I could work on > > it whenever I'm free. > > That would be awesome, but working with C bindings is a pain with > guile. If you inherit all the JWS and JWK code, I still need to keep > them around for things like hashing the URIs for the cache and resource > server and generating random numbers. The clever thing to do would be > to switch to guile-gcrypt first (so that I don’t have any more C) and > then move the code to guile-jwt (we can still change the API if you > prefer another one, I don’t have a 1.0 release yet). > > Oh, more duh! I actually saw it was in C the other day and I thought it would be cool to use guile-jwt (well, what I would like guile-jwt to be). I completely forgot. Actually, now that you mention guile-gcrypt, I started working on a branch for guile-jwt to use guile-gcrypt a while back ( https://github.com/aconchillo/guile-jwt/tree/gcrypt-port). I was waiting for a guile-gcrypt release (I basically upgraded the base64 module https://notabug.org/cwebber/guile-gcrypt/commit/f8934ec94df5868ee8baf1fb0f8ed0f24e7e91eb) to cut another guile-jwt release, but it hasn't happened yet (I just saw there's a new commit from Ludo...so maybe someday soon, Ludo? :-) ). > Since that code will most likely be run on web servers, have you > considered releasing it under the AGPL? > No, I have never thought about that... Aleix