~qaul/community

3 2

Re: Documentation feedback: technical intro

Alyssa Ross
Details
Message ID
<87k15vvvmp.fsf@alyssa.is>
DKIM signature
pass
Download raw message
> I rewrote the technical documentation intro to be more up-to-date and
> understandable.  I'd really appreciate some feedback on how it reads,
> if there's any explanations missing or if some parts are badly
> structured.

I like it!  I think this is a very good overview, and it's the perfect
level of technical explanation for somebody coming to the project who
knows what qaul.net is, but doesn't know how it works or how they coud
build on top of it.

Some small changes I would make:

> Fundamentally, qaul.net is a highly distributed system.  As such, it
> is not accountable to a single set of rules across all devices that
> are part of this system.  It is important to make the distinction
> between "qaul.net", the application, "qaul network", the distributed
> network of devices, and other components provided by the project that
> can be used to write decentralised applications.

I'd suggest "qaul.net" (the application), "qaul network" (the distributed
network of devices), here, because otherwise it's a little hard to tell
if the parenthesis is seperate list items or not.

> - [socket-ipc]() - using a capt'n proto ipc protocol over unix sockets

Cap'n Proto

> The idea behind the variety of IPC interfaces is that your application
> can bundle it's own copy of libqaul, to provide the network backends
> required to join a mesh network, however it can also connect with a
> running instance if one is available.  This way resources can be
> shared.

There are technical reasons for this beyond just "resources can be
shared", right?  Having a daemon shared by multiple applications is the
part of the architecture that surprised me the most, and so I think some
more rationale would be helpful here so people understand why it works
this way.

> The internals of libqaul are intirely written in Rust, and hook into
> various storage and networking abstractions.  libqaul primarily uses
> two libraries, also written as part of this project, to do it's job:
> alexandria, and ratman.

These are going to be links, I hope?


Finally, there are a couple of "it's" in the document that should be
"its".  :)

Re: Documentation feedback: technical intro

Details
Message ID
<87lfqb0vwj.fsf@kookie.space>
In-Reply-To
<87k15vvvmp.fsf@alyssa.is> (view parent)
DKIM signature
missing
Download raw message
>> The idea behind the variety of IPC interfaces is that your application
>> can bundle it's own copy of libqaul, to provide the network backends
>> required to join a mesh network, however it can also connect with a
>> running instance if one is available.  This way resources can be
>> shared.
>
> There are technical reasons for this beyond just "resources can be
> shared", right?  Having a daemon shared by multiple applications is the
> part of the architecture that surprised me the most, and so I think some
> more rationale would be helpful here so people understand why it works
> this way.

I mean, that's true, the technical reasons are there, but there's also
the usability aspect of it.

The idea was to expand qaul.net from being an app to being an ecosystem
of apps running on the same userspace protocol, meaning also that people
wouldn't have to create new users ID's and find people in every app.

There's a security implication here from the point of view of someone
using qaul.net in a riot that's just not present for people who use this
tech to build semi-permanent infrastructure that's used in their day to
day life.

Making communication easier is the primary goal, not security.  There's
apps like qaul.net that are entirely security focussed, and they're
completely unusable and useless.

For me the question arises how to communicatie qaul.net in general, when
the applications of it vary so much?


Anyway, I guess I'll add 1-2 sentences on this in the intro for now to
allude to why this is the case, and we can bikeshed project
representation and communication later ;)


~ spacekookie

Re: Documentation feedback: technical intro

Alyssa Ross
Details
Message ID
<87blr6x6o0.fsf@alyssa.is>
In-Reply-To
<87lfqb0vwj.fsf@kookie.space> (view parent)
DKIM signature
pass
Download raw message
>>> The idea behind the variety of IPC interfaces is that your application
>>> can bundle it's own copy of libqaul, to provide the network backends
>>> required to join a mesh network, however it can also connect with a
>>> running instance if one is available.  This way resources can be
>>> shared.
>>
>> There are technical reasons for this beyond just "resources can be
>> shared", right?  Having a daemon shared by multiple applications is the
>> part of the architecture that surprised me the most, and so I think some
>> more rationale would be helpful here so people understand why it works
>> this way.
>
> I mean, that's true, the technical reasons are there, but there's also
> the usability aspect of it.
>
> The idea was to expand qaul.net from being an app to being an ecosystem
> of apps running on the same userspace protocol, meaning also that people
> wouldn't have to create new users ID's and find people in every app.
>
> There's a security implication here from the point of view of someone
> using qaul.net in a riot that's just not present for people who use this
> tech to build semi-permanent infrastructure that's used in their day to
> day life.
>
> Making communication easier is the primary goal, not security.  There's
> apps like qaul.net that are entirely security focussed, and they're
> completely unusable and useless.

I'm very confused here -- I didn't mention security at all?

I just said that, as an outsider, it was surprising to me to discover
that there was a shared daemon, and that the documentation should spend
a bit more time on explaining why that is, since the reasoning was not
obvious (at least to me), and that as I recall there's more to it than
sharing resources.

Re: Documentation feedback: technical intro

Details
Message ID
<87imle29sx.fsf@kookie.space>
In-Reply-To
<87blr6x6o0.fsf@alyssa.is> (view parent)
DKIM signature
missing
Download raw message
> I'm very confused here -- I didn't mention security at all?

I think what happened here is that I heartbleeded myself.  Woops.


> I just said that, as an outsider, it was surprising to me to discover
> that there was a shared daemon, and that the documentation should spend
> a bit more time on explaining why that is, since the reasoning was not
> obvious (at least to me), and that as I recall there's more to it than
> sharing resources.

The reasoning is indeed not obvious and I'm gonna look into how to word
it better!

~k