-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Communication concept api.metaanchor.io #7
Comments
I'd rather favor an approach similar to (1), where each instance has 1 API-Key. Going with api.metaanchor.io as API and this github-repository as INSTANCE. Further using OWNER as the person who owns the smart contract and orders e.g. the MetaAnchor DevKit. I'd propose the following setup process for Single-Tenant; (ST1) OWNER fills out the order-form on https://metaanchor.io and lists
Multi-Tenant: |
Sligthly adapting the one above by splitting into "register instance" and "claim contract", which are essentially independently.
An INSTANCE only needs to be registered once (by any contract OWNER). For each contract, the contract owner has to log in at the INSTANCE and register the contract to the INSTANCE. Specs INSTANCE registration (#9 )
Specs Contract Claim (#10 )
Example In the present example, we have 3 smart contracts identified by CSNs Communications leading to that configuration:
edited |
In order to make it clear since both projects are distinct parts of the same ecosystem but different applications and each has an API/backend itself I'll call api.metaanchor.io as API and this project as a metaanchor instance, whether is backend or frontend.
In order to authenticate a metaanchor instance and make sure that it can call the API, it should have some means to authenticate itself and do the whole auto-setup of the API. This basically gives the API a way to do sanity-checking and health checks on the instance and it unlocks the instance to read and push information to the API. The workflow right now, from a customer point of view, is to register for a DevKit, grab the JSON (containing the API Key), and upload it to their instance so it can freely communicate with the API.
Right now, when signing up for a DevKit, the user must register where is their instance located. Thinking in terms of a multi-tenant or single tenant, they should simply place where their instance is running, and the DevKit sign-up form should simply present their API and any other relevant information. From that point forward, as long as the instance has this copy of the API it can "call home" and register that instance.
Now, I see two potential ways to do it:
(1) Most likely we don't need multiple API Keys for the same instance. Since the instance can simply communicate using the same API Key to the API servers, and inform with the data it carries which tenant is doing what action/operation (using their wallet for instance). The whole setup can be a one-time thing that the instance owner would have to do before other users hop on. In other words, an instance would have an API Key aggregating multiple users.
(2) Each user would be obligated to do the whole setup every time, and the application would have to do the job of picking which API Key to use to communicate with the API; the API Server would use the API Key to figure it out who's talking to them. This can be useful for sending back information to the API, but the other way around would be a bit problematic since the API would have to pick which API Key to use to communicate back with the instance, etc.
The text was updated successfully, but these errors were encountered: