Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Vivien Kraus via General Guile related discussions]

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/

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Jérémy Korwin-Zmijowski]

[-- 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 --]

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Nala Ginrut]

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/
>
>
>

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Vivien Kraus via General Guile related discussions]

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

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Dr. Arne Babenhauserheide]

[-- 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 --]

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Vivien Kraus via General Guile related discussions]

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.

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Aleix Conchillo Flaqué]

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/
>

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Vivien Kraus via General Guile related discussions]

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

Re: Demanding Interoperability to Strengthen the Free (Libre) Web: Introducing DISFLUID

[Aleix Conchillo Flaqué]

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