Just to make a note about this while it’s relatively fresh in mind, the thing that was quite hard to grapple with (but entirely understandable) was the functions like these ones that kinda just built up in quantity. I’m not suggesting any change here, all the names make sense and are useful, just it’s a complex space and trying to navigate across three services and their functions is not easy.
Authd will only be needed for folk wanting the managed account info/login + data storaage. You should be able to use all of the safe bin funcs with either an SK direct, or via some hardware wallet eventually.
It’s likely more like:
power user: download safe and use their own signing setup or SK directly. No authd needed.
Yeh that’s a fair observation.
It will likely be more like this in the end I think. We already have some of that w/ prior SNAPP iterations (downloading anything you need automatically for the user). Though non of this has been reflected in the CLI as yet.
Indeed. I’ve been through this pain myself. It was all very complicated.
Authd will essentially become another application on safe (instead of using specific APIs for it’s functionality as it does now) to manage your SKs. (You may notice in later versions on scl master there is no safe_app nor safe_authenticator)
There is safe vault run-baby-fleming -t which will perform the above for you, just FYI, essentially getting you safe to a usable state.
Protobufs are everywhere, especially if you happen to be working with or looking at Google-based systems, such as Android. Apple also uses a lot of them in iOS, and for people that have to support both operating systems, using a protobuf makes the pain of maintaining two different code bases slightly less annoying because you can compile the same definition to different languages.
For some reason this ycombinator thread about oauth3 bought this topic to mind. Seems to be a lot of grief over the polymorphic json.
The comment that stood out to me:
My take-away is this: Protocols should always be defined independently of any existing code.
(edit: I don’t completely agree with the above quote, but serializing objects from memory onto the wire seems like a potentially risky way to create an api.)
The current wire format for Safe Network is very closely tied to the rust code; the thing that mostly comes to mind is the use of enums, but to my knowledge there isn’t any polymorphic json in there.
Not really trying to make any actionable point here, just felt the oauth3 conversation highlighted some potential pitfalls and api ergonomics that are worth being aware of.
