00:17 <spacekookie> https://cryptpad.open-communication.net/code/#/2/code/edit/RQyjNQDmaVGGXrAf7k2ccwNd/

00:57 <spacekookie> I guess I mostly talked myself out of it again (see the feedback section :P)

09:33 <lejonet> spacekookie: without knowing more of the codebase and architecture, but here's my naive thoughts: What is it that is stopping you from abstracting the storage parts completely? I've worked a fair deal with distributed filesystems, currently mostly with ceph, and maybe a part of its abstraction regarding how you find objects could be borrowed?

09:35 <lejonet> Basically what you do there is that you have the monitor, which is the supervisors of everything, and then you have the actual storage nodes (OSD in ceph parlance, Object Storage Daemon) and when a client wants to know "Where can I find X?" they ask the monitor, which looks up in its tables and metadata which OSD that is storing it and tells the client "You can find X at node Y, go talk to them"

09:36 <lejonet> so basically what you could do here, is that you have some type of storage daemon, which abstracts where and how stuff is stored

09:37 <lejonet> so in this case, you'd mush the two things together instead of having it separated in frontend/backend, so that the actual storage daemon also fetches and delivers the data, not just tells the client where it is

09:40 <lejonet> Sure, architecturally, it becomes a bit more complex, and on few/single user systems, it might seem like a bit over-engineered, but it would follow the unix philosophy of one thing that does one job, well :)

09:40 <lejonet> (not to mentioned the added latency of handling storage, but that might be acceptable in some cases)

09:41 <lejonet> (and it would be up to the storage daemon to ensure everything isn't stored in one place, if that is such a concern) </naive brain dump>)

15:36 <spacekookie> Hmm, see in a way that's kinda already how it works now, except that the storage API is part of the main daemon that does the routing and everything lejonet

15:37 <spacekookie> I guess the idea was: what if we didin't need such a big daemon? On a single user system it's not really a big deal, but it feels weird having a daemon run as root and then having to like...write in people's home dirs and chowning the files afterwards

15:37 <spacekookie> Otherwise, maybe we do want to just keep the storage components in each service, and expose another slim library that does basically just that (encrypted storage for a user, for a particular service)

15:38 <lejonet> spacekookie: well maybe the storage daemon then should only be like the monitor daemon then, it keeps track of where stuff is stored, and then tells whoever asked where X is, to talk to Y, over there?

15:39 <lejonet> and then you have the "OSD" part like you said, as a small storage component in each service

15:39 <spacekookie> What's Y then? Another daemon that runs as the respective (system) user?

15:40 <lejonet> nah, Y is the storage component of the service

15:40 <lejonet> Might be an unneeded abstraction in this system, hence naive brain dump part :P

15:42 <spacekookie> Hmm, yea idk, I think it's an interesting idea, I'm not really sure how much the storage system should even do because...it's the one thing in the API that doesn't exist yet xD

15:42 <spacekookie> But this is interesting stuff to think about! :)

15:45 <lejonet> Basically what the abstraction would give you is that a particular service that needs information Y doesn't need to know where Y is stored, nor by whom/how, because that is what the "monitor" knows

15:46 <lejonet> so in a way, it would be a local file routing daemon for file requests :P

15:46 <spacekookie> Yea, that could work

15:48 <spacekookie> I think more interestingly actually is: how do we figure out who runs what actually, as in: right now the whole system has no concept of a system user yet and I'm wondering if it needs it

15:49 <lejonet> Yet again naive brain -> a system user is an implementation detail, so unless you somehow want to be able to directly adress the system with qaul messages, I don't see why you'd need one

15:50 <lejonet> You'll have the "system users" as the one running the process/es on whatever platform you're running, but dunno if you actually need that mirrored "inside" the system

16:04 <spacekookie> Hm, yea. I guess that's one way of implementing this xD

16:04 <spacekookie> Which might be complete overkill, but it does solve these issue

16:04 <spacekookie> +s

16:47 <spacekookie> Hey noracodes I'm wondering if you have a bit experience with poll_fn: I was looking at building an async interface for the native wifi direct stuff, but now I'm in the situation where I need to poll for something that itself has to await (to lock a mutex) and I'm wondering if you know how to use the context

17:21 <spacekookie> noracodes: got it xD https://img.pbb.lc/id/4OrKX4ErGw4mzIVx