Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
`libqaul` Service API #247
Following is a draft PR for the
Looking at the code, this will become very obvious. There are several
Okay so that's a lot of open questions. I'm curious to hear your thoughts and feedback. The actual
A note for Jess: this means that realistically the HTTP API interfaces need to be provided for the services that qaul.net exposes (messaging, file sharing, etc...), not this service API directly. (or rather, I don't think exposing the service API via HTTP is a very high priority, but could be done in the future).
Sync vs Async i feel waiting for
Registering Services? So if i'm understanding this correctly services would be authorized per user? i'm wondering if there's a use for a more fine grained permission system, also in the OAuth direction, where for example you could authorize an application to view your profile but not delete it. That might add too much complexity though.
HTTP API i'm presently structuring the api such that each service should be able to provide it's own section of it so i don't imagine this service api being exposed at all.
On 19-06-26 07:47, Jess wrote: **Registering Services?** So if i'm understanding this correctly services would be authorized per user? i'm wondering if there's a use for a more fine grained permission system, also in the OAuth direction, where for example you could authorize an application to view your profile but not delete it. That might add too much complexity though.
I actually kinda really like this idea. Especially when it comes to dealing with potentially malicious services, this could also prevent some damage. It's probably out of scope for now, but something we should definitely have on the roadmap!
**HTTP API** i'm presently structuring the api such that each service should be able to provide it's own section of it so i don't imagine this service api being exposed at all.
Cool! We should sit down after this (or maybe at the same time), and talk about what kind of API the actual `qaul.net` services should have. Obviously messaging is pretty simple, then there's file sharing (which is essentially messaging but with large attachments and stuff. And then VoIP (which isn't really over IP at all but eh 🤷).
i'd prefer the former. Context structs are much more natural in rust and to a certain degree we'll need to build wrappers for the c api to deal with the regardless (for external structs like
Sure, yeah. i'm presently working on the few layers of middleware that sit above all incoming requests but once I'm done with that that will be an excellent discussion to have.
On 19-06-27 06:43, Jess wrote:
Ah damn, yea I had completely missed that! There should be,
I was leaning that way too. I'll add a context struct at the root of
An app initialises
Also something else to consider: We have multiple layers of objects
We already discussed that in a message, the
Next up, the messages: I think the biggest difference between a
Realistically the signature should be replaced with an enum like:
enum Signature Valid(UserID), // Verified with this users pubkey Unverified(UserID), // Unverified message from a user Invalid, // Failed validity checking: danger! }
This way the cryptography is done inside
At which point, the message layer is essentially the same from just
... anyway, sorry for rambling. Thoughts?
(reposted from the web-view because github emails don't allow markdown :( )
Yes, please do that.
I think this is a good idea; unifying identity across as many levels as possible is certain to be beneficial to development speed and security.
On 19-06-27 10:59, Leonora Tindall wrote: My big question here is, do we expect each qaul.net application to have it's own set of registered services, or do we want the user to run some kind of qaul.net daemon onto which services register?
This is something that @luxferresum and I had a conversation about and figured out a cool idea: every service that wants to use a `qaul` network is gonna bundle a copy of `libqaul` anyway, right? And there's probably already a platform specific wrapper involved, like an android shim or something that creates a linux daemon or whatever. Then in this shim we can do one of two things: 1. If we are the only/only qaul service running on the device, we take ownership of the network. This is essentially what `qaul.net` will do. 2. If there is another service running on the system, we do some $IPC_MAGIC to connect to it, so that it can then re-use the registered users, etc. On Android this can be done via intents, on Linux via checking if some service is running (or checking some socket/env var/whatever.
A change I kinda wanna make is removing the
I kinda wanna merge this PR soon, just so it doesn't get way too big. @NoraCodes you could then just add the digest stuff you wrote for a message to the
Again, I've taken a very crate-happy approach in the beginning. I wasn't entirely sure how many cyclical dependencies we might end up with. Or what types needed to be exposed to what other
The API is now using a struct and associated functions, all of them read-only. I sugest we use lots of internal mutability to make it all work.
Anyway, I'll merge this PR after this then and we can move on from there.