There’s chatter here on the forum and on Discord about application interoperability, higher level libraries, and in particular, a common authentication mechanism for apps. Before we all go off and reinvent the wheel, I propose that we form an Autonomi Developer Council (or whatever we want to call it) to share code, ideas, and proposals to see if we can form some best practices for our fledgling network. I would also like to propose that the first topic on deck for this council be a common authentication mechanism since we’re all starting to face this one in our apps as we move forward.
As for format, discussions on the forum are great, definitely don’t want to stop anything gong on here, but I believe it would be good to have a weekly 1 hour conference call where we can hash out ideas in real time and provide weekly meeting minutes to the forum on topics discussed.
Starting one of these things is the hardest part, so I say we just start running and see where it takes us. What do you guys think?
I think the hardest part will be keeping this going, but whatever we call it the idea is good and I support anyone trying to coordinate and gather a consensus. I am unlikely to join in weekly calls, but don’t let that stop you. Whatever works is good and I will contribute where I can.
It was like that on old Safenet, and I don’t think separating this in 2 fields is necessary if we don’t want to use username for identity, just need to generate a private key.
I have a wallet for ACT, that stores amounts on tx+output pairs for every public key, wonder if it could use the same infrastructure together with other apps.
There are mechanisms in OSes, like PAM in Linux, perhaps it could be used to log into Autonomi? Like, if you are logged into your system, perhaps you don’t need to log into all the apps additionally? Trouble begins if someone else wants to use your computer or you want to login from a library.
I think we don’t need a council as long as all development and communication is public, and everyone is allowed to read and comment in a transparent way. And live calls can be open on platforms like Jitsi Meet or (cough!) Discord Stages.
Please no more Discord Stages. I realize that some people here are absolute privacy freaks, but we have got to move beyond the agoraphobic nonsense. The network is working and it is time to shout it from the rooftops. People who want to remain low-key can do so via side chats.
Sounds like there is some interest! I’ll work on setting up an agenda for a kickoff meeting.
Agreed. I use the term council very loosely, mostly for lack of a better term. Everyone is welcome, but the conversation will be heavy on the technical side, so many will not get much from it. I’m thinking we post a weekly status update here on the forum that summarizes what we’re talking about to keep the wider community engaged.
Onto some logistics. What conference call platform would you guys prefer? Sounds like discord is out. Jitsi meet is good in my opinion. Anyone have a different preference? If I hear nothing, I’ll use Jitsi.
As for time, I’m on the east coast of the US. Based on the forum posts, I gather most folks here are either in the US or Europe. I’m also guessing that most of us aren’t driving lambos yet and have day jobs. Scheduling could be difficult on weekdays. Couple weekday options:
9AM LA → 12PM New York → 5PM London
2PM LA → 5PM New York → 10PM London
I work from home so I can block out an hour relatively easy, lunch time is always open. Any preference on day or another time slot?
One other note, it would be good to have representation from Autonomi on the call to answer questions, field requests, and just keep a good line of communication open. Is there a dev from Autonomi that would like to volunteer? To be clear, this is for technical discussions only, so no grumbling about company decisions, etc. We’ll be nice, I promise
If we don’t have that every app either requires you to ‘login’ with the same systematic and every app knows the root of your derivation chain (or the chains are disconnected… Which would be a pity) and if one app doesn’t handle the root secret right all your app ‘logins’ are unsafe…
Derivating from somewhere with library is fine - but putting the root for all your passwords into every app sounds even worse than the current version of the Internet and how it’s done there…
And only for mobile they seem to be able to limit secrets on app scopes.
So if you install a bad app it can simply ask for permission to the keyring (which every app needs to store their own secret - so not fishy) and when it has access it just asks for all secrets from all apps
Yes that is one of my immediate concerns is that if you require the use of the same 12 word phrase for each App then there will be a mimic app that will farm these, some time in the future.
Then as you say the derivation chain
That is why the idea of an Autonomi account which can be used by everyone and it allows the storage of keys needed by Apps and the user can give the key to them if they want, or start a new chain for each app.
You associate the App to the key or chain in the account App.
Thus no app ever gets your phrase and no matter how much you trust the App writer there will always be one or millions of Apps out there that will not keep it secure on your machine only
Obviously the Account App will have to be checked for bugs or flaws
and preferably won’t base the root of everything onto your Arbitrum Payment Private Key … so you can switch between payment addresses / drop one if it got corrupted & without loosing control of all connected apps too …
so we need a modified hardware wallet for autonomi
using BLS keys instead of secp256k1 … and creating a BLS signature …
TREZOR is opensource software - is there a way to install custom firmware on a trezor?
(I think that should work xD … that’s kind of cool )
passphrase wallets could be the app names (the different derivation chains) - API to e.g. Metamask could be the same; Metamask doesn’t even know there’s something else under the hood generating the signatures and typical Metamask plugins could be used to get data signed externally to get a derivation starting point (public key of your app names passphrase wallet)
…ofc this doesn’t precisely reduce friction xD …
EDIT:
TREZOR has only 256KB RAM - we cannot sign largish content (graphEntry/Scratchpad) with it.
since we’d be only using the hardware wallet as external service to get to a starting point to derive our private-key-chain for this app … we could just use an unmodified wallet, hash the ethereum address of e.g. the passphrase wallet “friends” and use that as seed for deriving deterministically the root-scratchpad-private-key for the app … since the wallet doesn’t get used to emit transactions it wouldn’t be a known address on the blockchain …
…the address is just kept in Ram and never gets stored on disk …
…I think then we couldn’t go through metamask because that stores public keys but would need to interact with the hardware wallet directly… it would be a somewhat expensive 2nd factor … but would be possible …
then maybe more or less @loziniak s idea with the library would be on the table again …
a library object that get’s passed e.g. username+password + appname(/xor-address); that derives the initial user account and from there the app-specific root-key and returns it …
so one login for all apps … but ofc a malicious app can derive other root-keys too once the user entered the seed …
the idea with the hardware wallet is to be able to restore all keys for all apps from one singled seed
To require a piece of hardware to access account makes for a higher barrier to adoption, especially for the poor and less tech people (majority of the earth)
it should be easy … it’s super clumsy too … people go for the option with the least friction …
edit:
ideally the user - when opening an app - would automatically bring that object and by interacting with the app it should automatically be configured to only output the derivation path that is the context of the app …
the app then would ideally just present the data and ask for a signature / request the next address in the derivation chain / present encrypted data and asks for a decrypt …
