Support registering an account to the allowlist

[Mirko-von-Leipzig]

Summary

Adds a new gRPC method to register an account using an invitation code.

The method is idempotent, and rejects requests which specify an unknown invitation code or which attempts to register an account that is already registered.

Changelog

[[entry]]
scope       = "rpc"
impact      = "added"
description = "Added `RegisterAccount` which adds an account to the allowlist using an invitation code"

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[Mirko-von-Leipzig]

@igamigo this is what I had in mind. Let me know if this isn't suitable for some reason?

An open question is whether the invite code should be a string or bytes, but I feel like a string makes more sense so it can be used manually.

[Mirko-von-Leipzig]

Another question is funding.. at the moment I'm thinking a separate side car service that polls the admin API for new account registrations and sends funds that way.

One alternative would be that RegisterAccount uses the funding service we are building, and sends the private note to the caller as part of this registration?

This would be less work, but does tie registration to funding which may or may not be desireable from the client side.

[Mirko-von-Leipzig]

The other downside is that using the admin api to register an account directly, would also have to return the funding note - and that flow doesn't make much sense.

[Mirko-von-Leipzig]

cc @bobbinth, this is probably also a good point to get your input on.

[Mirko-von-Leipzig]

A cute option is to use the note transport service.. or to make the notes public in any case? Using the transport service is elegant but couples a lot of infrastructure to it which may or may not be desireable.

Dog fooding = good, but having everything die because one service is down is less good.

[bobbinth]

I would let the client discover the note on their own. This should use already existing mechanism and so avoid specialized new code for this use case.

[Mirko-von-Leipzig]

There is no client in this case; so its much more code because we need to recreate a client specifically for this.

[bobbinth]

Do you mean to create the notes or to consume them? The consumption will go through regular wallet flows - so, if we create a public P2ID note, everything else should work as it currently does (i.e., no need to specialize anything).

[Mirko-von-Leipzig]

Sorry I think we're slightly missing each other here.

Our infrastructure accounts e.g. the monitor, also require funding. And they don't have a proper client, just whatever we code there. They'll be using this funding service to remain topped up, but for them its easier if they either receive the full note info or at least the note ID so they don't have to poll and sync notes constantly.

They also have to register; but we can register them directly via the admin api.

[igamigo]

Two cents on this:

• I'd agree with using the funding service for this. I don't think it's bad that this couples infrastructure as it should be a short-term solution anyway
• I'd still make the funding service return the note as bytes. The note can be returned optimistically (e.g., before the note actually exists on a block). The registering endpoint may still want to discard it, but for other usecases I believe this is useful. EDIT: basically for what Mirko said, the conversation updated when I posted my comment

[igamigo]

LGTM!

[igamigo]

Two cents on this:

• I'd agree with using the funding service for this. I don't think it's bad that this couples infrastructure as it should be a short-term solution anyway
• I'd still make the funding service return the note as bytes. The note can be returned optimistically (e.g., before the note actually exists on a block). The registering endpoint may still want to discard it, but for other usecases I believe this is useful. EDIT: basically for what Mirko said, the conversation updated when I posted my comment