because it would work and would be a valid solution (for applications that can scan QR codes; + all apps then need to be able to process that etc. but as you say could be part of a lib) but was unexpected for me … and requires an external device again … + you need to trust that device but install an app on it → that would work … but for sure not for 3/4 of my family
I wasn’t sure I should 
or 
or 
since we’re just spitballing …
Dieffie-Hellman …
(if 2 parties know the public key of each other; and obviously know their own private key; they can both calculate all by themselves a common secret by combining their private key with the other parties public key … nobody else can know that secret)
if we had an auth-app that can somehow be communicated to (one way) - e.g. by a System-Uri scheme. That could be handed a request; it could derive a root private key for the app; and could store it at a place derived from their common secret.
the app then would need to know the public key of the auth-app.
… if the app knows private keys of other apps we’ve our pants down again … which with opensource software - without additional passphrase - would be very possible …
This might more sutitable to be arranged via @rusty.spork ?
btw. I think discord has such more tech specific channels with such similiar purpose ?
Using a temporary session key, storing the encrypted root (app) key into a scratchpad that can stay the same for the lifetime of the app (used by this one user; the app makes sure it persists the data to know where the scratchpad is to just be able to update it later and not needing to pay for every login …) … then for every login the auth-app would open, the user confirms he right now wants to log into this specific app … and the login is successful after the scratchpad upgrade has propagated to the network (the app can poll and waits for data it can validly decrypt)
…so scratchpad update time would be the time needed for a login authenticated by an external authenticator app (but ofc can cache user data locally - so it doesn’t need to look broken while the login happens in a background process); the app itself wouldn’t store the session key and would use a new one for every login and (app) root private keys would just exist in ram while the apps are running …
okay - now I need to do other stuff - feel free to criticize / comment / enhance / expose / …
Yes good point, and might I add that dweb avoids this for web apps by deriving a key for each app from its app ID. 
In fact apps using the REST API don’t currently see the private key because that’s held in dweb and derived for each request.
I think dweb could act as a key-server for other apps though - they can request their secret key from dweb (and dweb can open a browser window to allow the user to confirm that access). Access to the public key for any app ID could be provided without user confirmation, and the user could also have control over how dweb responds to such requests (in dweb settings).
Of course it doesn’t have to be dweb - we would just define a REST API which any key generating app could implement - so up to the user. But dweb is already doing this so would be an easy option to try out and test with various apps.
In summary, the minimum services would be
etc).The downside is of course having to run the key-server app on any device running apps using this scheme. The upside is only one master key/recovery mechanism for all those apps.
In specific use cases, apps can of course implement this themselves and the user can choose whether they want that or not. We can also encourage apps to act as key-server for each other (by providing library calls to do the work). The downside of that is again every app gets access to the master secret key.
I think you either have to have a trusted key-server, or a key/login/recovery mechanism per app. So I suggest we implement the key-server, but accept some apps will be better handling their own key and key management.
Dweb gets it’s root key from am env variable and doesn’t require a login - right?
(that’s just something that may be changed for Desktop but for this to be used on mobile later on might turn out to be problematic..? No..?)
Since I’m on dweb anyway I am keen to try out the dweb keys server 
Yes.
I don’t expect that to be the normal way forever - I’ve been waiting for someone else to do the hard work which we’re starting in this thread. 
After thinking briefly about what I wrote above I do not think this is the way to go about this though.
I really think it needs to be:
Even I can see a lot of issues around designing this to be secure, as well as being a good solution to the UX issue we have focused on. I’m definitely not experience enough to do this job. Maybe someone like mav has the experience, but it needs a specialist IMO so I’m surprised Autonomi think it can be done by the community.
Maybe because people like mav and oetyng are in the community =D
It’s okay I can always fall back to username+password and/or use a different way to get to my settings/account Scratchpad
We don’t know if they or anyone here have the experience or inclination to take this on - it’s a much bigger task than it seems, so really should be done by someone who has literally done this before.
But the other issue is that by Autonomi creating this they give confidence, can ensure it integrates with their view of the API, can get it audited and promote the advantages over multiple login solutions as part of the Autonomi offer to developers and users.
I’m not saying that can’t be done by the community, but it’s a lot less likely to happen any time soon otherwise, and it’s very important to get it soon and get it right.
Otherwise we’ll have something much less impressive when people arrive and get put off by a poor UX across different apps.
Or write a little web app to create a Vault that holds the user’s keys and tells dweb what to use for payments, and optionally for different use cases or apps. 
As with the Community Native Token.
And I would rather we had that very right than very soon. But I do want both.
Great conversation here. It sounds like we’re well on our way. Back to the boring stuff (I know, I’m sorry), I’ll setup a weekly call on Jitsi Meet on Tuesdays @ 9PM UTC starting this coming Tuesday 2025-05-20. Here is the user link: Jitsi Autonomi Developer Council Call
For this first meeting, I think we just roll with this particular topic and hammer out some details, because its more interesting than what I’m about to talk about 
.
Moving forward, we should codify these proposals into a framework so we can keep track of them and have consensus on how to deal with changes in the future. Autonomi, being an open source project, and MaidSafe, being a company, it would be very valuable to have a structure in place where if MaidSafe must dissolve due to legal warfare or whatever, we have a community driven structure in place to help keep the network from dying a slow death of entropy.
We don’t need to reinvent the wheel here though. The Bitcoin Improvement Proposal (BIP) is very well thought out in my opinion and it being a successful autonomous network, I think we could follow many of the same conventions. Another benefit to this is as Autonomi becomes more successful, developers from crypto projects would be able to move to our network and be in a rather familiar environment. The repo for BIPs can be found here: GitHub - bitcoin/bips: Bitcoin Improvement Proposals
I propose that we create an Autonomi Improvement Proposal (AIP) framework with AIP-1 being reserved to essentially copy BIP-2 and BIP-123. We would create a repo on the safenetforum-community · GitHub github to store these.
Then with all this paperwork out of the way, AIP-2 could describe our common authentication mechanism. This would naturally fall into an application layer standards AIP (using the description from BIP-123).
So all that said, yes, very boring stuff, but the network is alive and running today! We need to start organizing as a community to keep it that way and have a support structure in place to handle the tidal wave of proposals and improvement requests that will come as millions of people around the world begin to utilize its potential. Better to start now while we’re ahead than to be caught flat footed.
If folks are agreeable to this, I will setup the AIP repo on the safenetforum-community github and begin crafting AIP-1 from BIP-2 and BIP-123.
Maybe, maybe not. There are a lot of smart people here. As a community, we could come up with a rough specification or at least a list of user level requirements that a specification could be based on. From there we would need a champion to flesh out and implement the spec. Typically what I’ve seen from other projects is that someone comes out of the woodwork and picks it up, especially something this important.
And its because guys(and gals) like you are prepared to get stuck into the boring stuff NOW means we should have a lot less contentious boring stuff to sort out later.
Obv nothing will go 100% the way we want it 100% of the time. Having structures like the BIP in place now and some sensible guidelines will keep us close to the right track as we move forward,
Well done and thank you for taking the lead on this.
OK I’ll talk to @rusty.spork
Really we are just sounding out the senior devs to who would be interested in taking a position on this as yet kinda nebulous Community Developer Council/Forum/Gabfest
But looks like @zettawatt is firming it up <— ooh err, missus
I don’t know how it compares with BIP but we’ve had RFC (Request For Consideration) here for a while and they seemed a good, well defined way of doing this.
They were getting used a while back but Autonomi haven’t used them for a while. Anyone could write one, I did one myself, but most were by the core devs. All public, reviewed and merged on GitHub. Might be worth looking before choosing BIP to see how they compare. I think MaidSafe did consider BIP when setting this up.
I went on brave and asked the difference between RFC and BIP. TL;DR: I think BIP makes more sense from the way Autonomi will change in the future and the developer pool we will be leveraging:
RFC vs BIP
Both RFC (Request for Comments) and BIP (Bitcoin Improvement Proposal) are mechanisms used to propose and document changes or improvements in their respective domains. However, they serve different purposes and have distinct processes.
In summary, while both RFCs and BIPs serve to propose and document changes, they differ in their specific purposes, versioning, authorship, approval processes, and the types of documents they produce. RFCs are broader and more formal, focusing on internet standards, while BIPs are more community-driven and specific to the Bitcoin ecosystem.
I think it’s questionable whether asking an LLM is a good way to evaluate this so I’m not convinced by that one way or the other.
When I use them I frequently find basic errors in the response so I generally use them only for things I know well enough to evaluate the response.
If you use them for things you don’t already know about you need to check the results are accurate, so in a case like this IME they aren’t helpful. It may be 100% correct, but you don’t know that.
Always thought it was “Request for Comments”.
not that it matters but Im in a particularly pedantic frame of mind tonight
hip hip hip for BIP
Fair point. I dug in further, but the LLM summed it rather nicely. We can go right to the source: bips/bip-0001.mediawiki at master · bitcoin/bips · GitHub
Basic idea for a BIP:
This is essentially a framework for how to drive and manage community driven proposals. The Bitcoin folks didn’t invent it, it is similar to Python’s PEP-0001, which defines how that language is developed.
For RFC RFC 2223: Instructions to RFC Authors , I understand it like this:
This is a much more centralized system, which would make sense for something with a company backing it up and processing the changes, like MaidSafe. Someone has an idea, posts a RFC, the company/organization thinks about it, and decides what to do with it.
Or as summed up in some other descriptions, an RFC has an author while a BIP has a champion. I feel that the BIP/PEP process is more suitable for a community driven effort vs the RFC process. And yes I wrote all of this with real neurons, though they may be struggling through a slight haze of Knob Creek