Supermind API
Goal
Create API endpoints for the Supermind service.
What needs to be done
Superminds will support multiple currencies, Tokens and USD (stripe). Only offchain tokens will be supported for the initial phase.
We should use vitess as our datastore. Proposed schema (subject to change):
Schema / Data structure
CREATE TABLE superminds (
guid bigint, // Should this be the guid of the activity supermind request or another column
sender_guid bigint,
receiver_guid bigint,
status int, // enum
payment_method text,
payment_txid text,
created_timestamp timestamp,
updated_timestamp timestamp,
PRIMARY KEY (guid)
)
Status enums
Enum | Status |
---|---|
0 | created |
1 | accepted, replied |
2 | sender revoked |
3 | receiver rejected |
4 | payment failure |
5 | request expired |
API outline
Method | Endpoint | Description |
---|---|---|
DELETE |
api/v3/supermind/{{guid}} |
REVOKES a supermind request |
POST |
api/v3/supermind/{{guid}}/reject |
REJECTS a supermind request and refunds the requester |
GET |
api/v3/supermind/inbox |
LISTS all supermind requests received |
GET |
api/v3/supermind/outbox |
LISTS all supermind requests sent |
Creation flow
All Supermind Requests are Activity posts. All Superminds Replies are both Activity posts and quote posts of the original Supermind Request.
Therefore, Supermind posts should be created from the composer and pass data via payloads.
For example a request:
POST api/v2/newsfeed
{
...
"supermind_request": {
"receiver_guid": << guid of receiver >>,
"payment_options": {
"method": "usd",
"usd_payment_intent": "pi_ref << stripe payment intent >>",
"amount": 100.00
}
}
For example a response:
POST api/v2/newsfeed
{
...
"supermind_reply_guid": << supermind guid >>
It is recommended to use the Minds internal events to tap into the Activity save events if possible.
Payment
Cards should not be charged until a Supermind reply has been made, instead use an authorization. Once a reply is made the card should be charged. If the card fails to charge the Supermind should be marked as payment failed
.
Ensure we add a reference to the the supermind_guid on the payment metadata.
Token balances should only be charged at time of reply. Avoid using an escrow. If no fund available at time of acceptance, mark as payment failed, insufficient funds.
Expiry
Supermind requests expire after 7 days. Card holds should be automatically released after this time. Only status created
Superminds can expire.
Talking points
- Confusion over supermind request and supermind reply. Designs have the same badge on both, but they need to be distinguished.
- Audit state changes. Consider snowplow.
QA
UX/Design
N/A. This is a backend task.
Personas
All
Experiments
Introduce with a new experiment and enable with a feature flag.
Acceptance Criteria
-
Create a new Supermind module -
Add new api/v3/supermind
routes -
Implement new data structure as mentioned above -
Support for usd (stripe) and token (offchain) payment methods -
On replies
save asupermind_reply_guid
field to the activity entity -
On request
savesupermind_request_guid
field to the activity entity -
Index the supermind_reply_guid
andsupermind_request_guid
fields on elasticsearch -
Garbage collection job to mark supermind requests older than 7 days as expired -
Integration and spec tests
Definition of Ready Checklist
-
Definition Of Done (DoD) -
Acceptance criteria -
Weighted -
QA -
UX/Design -
Personas -
Experiments