Open gobengo opened 1 year ago
this is a little related to https://github.com/web3-storage/w3protocol/issues/182
store/list
invocations against access-apitest here. store/add
invocations are also proxied ok to upload-api handlers, and currently get a result from this in upload-api
store/*
or upload/*
invocations, they will be proxied to be handled by the upload-api running on aws.This was the gist of how @Gozala and I decided to do it (especially at the time in January).
Motivation:
To Do
Problem
Solution
can
of invocation, determine backend ucanto service that can handle it, i.e. upload-api or access-apiNice to Have
did:web:web3.storage
did document links to the ucanto api via service endpointaud
ofdid:web:web3.storage
to the URL you should send ucanto invocations to:aud
- fordid:web:web3.storage
, this means GET https://web3.storage/.well-known/did.json"service"
property for a service endpoint of typeucanto
aud
, which you need anyway to create the ucan invocation.Decisions
✅ What should the URL be of the unified ucanto endpoint?
Status
Ideas
@web3-storage/api
handler. This is kinda nice as it enhances our existing/legacy API URL with ability to handle ucanto http requests by proxing to the new microservices.✅ Should the unified UCAN API endpoint respond to websocket connections?
Status
Context
w3access create-space
, when it will connect to websocket to find out when the email has been confirmedProblem
Considerations
Solutions Considered
#access-api
and/or service of typew3protocol.web3.storage/services/access-api