SAFE communication protocols

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.

safe-client-libs

handle_response
handle_new_message
handle_sent_user_message
handle_unsent_user_message
handle_unsent_request
process_request
process_client_req

safe-vault

handle_routing_event
handle_routing_message
handle_client_event
handle_action
handle_vault_rpc
handle_client_message
handle_request
handle_response
process_client_request

safe-api

handle_request
process_jsonrpc_request
process_command
process_req
process_tree_command
process_get_command

routing

handle_request
handle_response
handle_consensus
handle_info
handle_dkg_result_event
handle_parsec_block
handle_parsec_request
handle_parsec_response
handle_message
handle_messages
handle_untrusted_accumulated_message
handle_untrusted_accumulating_message
handle_dkg_message
handle_accumulated_message
handle_accumulated_event
handle_user_event
handle_selected_operation
handle_transport_event
handle_new_message
handle_unsent_message
handle_sent_message
handle_untrusted_message
handle_unknown_message

2 Likes

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.


Thanks for all this, @mav . Super useful insights :+1::bowing_man:

3 Likes

Came across this about protobufs today, I wasn’t aware Apple uses them so much.

https://ciofecaforensics.com/2020/09/18/apple-notes-revisited-protobuf/

Why Care About Protobufs

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.

3 Likes

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.

2 Likes