Using dat-daemon as a service - cross-platform

[martinheidegger]

I would like to integrate dat-daemon in dat-desktop as the implementation that does the actual downloading and sharing. But if bundled with dat-desktop there needs to be

• a binary version of dat-daemon executable that includes Node. (Maybe an installer?) That can be used to install dat-daemon on the platform.
• a way to see if the version of dat-daemon installed outside of dat-desktop.
• a way to ensure that the right version of the dat-daemon protocol is running (semver-ish)

I saw that node-windows, node-mac and node-linux provide a way to start a Service on the major os's.

But I worry that permissions might be tricky. Maybe a ~/.dat-deamon could hold a port & password for the daemon running for the current user. In an initial handshake, a client could then provide the password to make sure that the client is allowed to actually access the data?

[martinheidegger]

Maybe an approach like 1Password is a good idea? https://medium.com/@paulsc/making-a-1password-client-15dd39ac1642

[soyuka]

a binary version of dat-daemon executable that includes Node. (Maybe an installer?) That can be used to install dat-daemon on the platform.

Yes this was my thought as well! It can be packaged via https://github.com/zeit/pkg for example.

a way to see if the version of dat-daemon installed outside of dat-desktop.

I've started a small add-on (tray icon) that does just that and gives you visibility over version, http, daemon etc. https://github.com/soyuka/dat-daemon/tree/master/packages/add-on

In an initial handshake, a client could then provide the password to make sure that the client is allowed to actually access the data?

I'm not sure why this would be required if everything runs locally only. I mean as long as it's not accessible from the outside, I don't see any harm.

[martinheidegger]

Yes this was my thought as well! It can be packaged via https://github.com/zeit/pkg for example.

Awesome! Seeing as the executables/installers would be good to be signed by the same authority it might be good to have dat-daemon in the same org as dat-desktop (with people having the same publisher certificate)

I've started a small add-on (tray icon) that does just that and gives you visibility over version, http, daemon etc. https://github.com/soyuka/dat-daemon/tree/master/packages/add-on

I wonder if this shouldn't be part of the Dat-Desktop: seeing as it is visual, related to the desktop?!

I'm not sure why this would be required if everything runs locally only. I mean as long as it's not accessible from the outside, I don't see any harm.

It is possible that two users are active on the same computer (multiuser-system). In that case the linux filesystem permissions prevent user-A to access files of user-B. Is it a good idea that "sharing" with dat means that all the data will be accessible to all local users?

[soyuka]

I wonder if this shouldn't be part of the Dat-Desktop: seeing as it is visual, related to the desktop?!

Definitely!

It is possible that two users are active on the same computer (multiuser-system). In that case the linux filesystem permissions prevent user-A to access files of user-B. Is it a good idea that "sharing" with dat means that all the data will be accessible to all local users?

The easiest would be to have 1 daemon per user (1 dat-desktop app per user?) and to allow data transfer on a socket:// file to avoid using public ports. This way user-B could not access user-A data.

With a system-wide daemon things are more complicated and we need to set up some kind of authentication indeed... The key exchange from the 1password article could work indeed but this is a lot of overhead to add.

[martinheidegger]

The easiest would be to have 1 daemon per user (1 dat-desktop app per user?) and to allow data transfer on a socket:// file to avoid using public ports*. This way user-B could not access user-A data.

Uhm. I dont understand what you wrote here 😅

[soyuka]

By having 1 daemon per user it may facilitate security (on top of other things) in a multi-user environment.

[martinheidegger]

I understand that, what I don't understand is how those daemons communicate.

[soyuka]

I understand that, what I don't understand is how those daemons communicate.

Yes I need to think about it, currently it's using websockets but it could be tcp or any other network protocol.

I think that we need to find out what are the actual use cases of a daemon, and how these use cases fit in a multi-user environment...

By using tcp for example, we could leverage socket files (at least on unix systems) to introduce user ownership and get rid of the security issue.

dat-desktop => [tcp] => dat-daemon
dat-cli => [tcp] => dat-daemon
webextension => [http] => dat-daemon-http => [tcp] => dat-daemon

The main reason I use websocket for is that you can have open connections on different paths. When you readFile for example, the current implementation does something like this:

connect on ws://localhost/read/386ef60e56eb9edb878738ee35ee6e95c8552902985e725a5901ae6851e25d00/dat.json
receive stream
end

With tcp it'd be a bit trickier to implement:

connect to ~/.config/dat-daemon/dat-daemon.sock
send READFILE 386ef60e56eb9edb878738ee35ee6e95c8552902985e725a5901ae6851e25d00 dat.json
receive stream until end instruction? What if other instructions are being sent at the same time? 

[soyuka]

Note: look into grpc.