Goals
- Use may want to pin data in the remote IPFS node for availability.
Proposed solution
At the moment dealing with UI is probably not the best use of our time. Instead we can create special URL pattern such that navigating to it would add a pinning bot to the lunet. e.g.
https://lunet.link/@invite/pinbot/https://mypinningbot.sh?token=apiAccessToken
Above will add pinning service with a name pinbot to the registry. On pin requests it would issue request to the provided url https://mypinningbot.sh?token=apiAccessToken and pass API access token via query argument.
Lunet will not know when user wishes to pin data there. In long term app will issue request to lunet triggering share user interaction, where user will be able to choose who (bot or person) to share with. But in the meantime we could introduce yet another URL pattern to address that e.g.
https://lunet.link/peerdium.gozala.io/${CID}@pinbot/`
Could tell lunet to load CID document into peerdium.gozala.io and pin all PUT requests into service named @pinbot.
Goals
Proposed solution
At the moment dealing with UI is probably not the best use of our time. Instead we can create special URL pattern such that navigating to it would add a pinning bot to the lunet. e.g.
Above will add pinning service with a name
pinbotto the registry. On pin requests it would issue request to the provided urlhttps://mypinningbot.sh?token=apiAccessTokenand pass API access token via query argument.Lunet will not know when user wishes to pin data there. In long term app will issue request to lunet triggering share user interaction, where user will be able to choose who (bot or person) to share with. But in the meantime we could introduce yet another URL pattern to address that e.g.
Could tell lunet to load
CIDdocument intopeerdium.gozala.ioand pin all PUT requests into service named@pinbot.