How exactly does the Lume API work then?
This is where it gets fun.
I know I have gotten a lot of heat for the direction my project has taken (most criticism is warranted)… But overall I am trying NOT TO define my own API’s. I stopped doing that after 2023. I think the best term is aggregator. I am building an aggregator for the ecosystem. I defined custom API’s for the account, admin, abuse, b/c I had to, but any time a HTTP proto exists for an ecosystem, I will just use that.
Every integration is a plugin that has a API and Protocol entity/class (in short… an interface). More recently there was an APIExtension entity added (so abuse could sainly tag onto the admin API).
All plugins are compiled into the portal as side effect imports technically _ "portal-plugin" which then register themselves (akin to a ES6 TS import that runs global code) . This was inspired by caddy. So where possible, the plugin embeds the protocol, though its certainly possible, and required for some in the future, like bluesky or iroh, to run a second server due to language barriers (no go impl).
Hosting wise, you must use wildcard DNS as the HTTP logic uses vhosts effectively to route everything. Its all an integrated framework to serve API’s and operate protocols based around user pins.
Also know from a technical POV, every protocol gets a dedicated bucket in renterd. That part is actually the more simpler aspects of the system.
Upfront, no integration will give a free open gateway over HTTP to users (social media is going to need to be handled carefully). Basically I am not repeating Skynet and that has been a real hard line ive taken since I started on the portal in 2024…
In the near future, a quota plugin (with a new simpler billing plugin with it), will enable the bean counting, and direct IPFS leeching will be supported, but the block availability is actually subject to a ready column in the db for a given block, which the blockstore checks… So the node side of the plugin will fail when bitswap WANT requests come in. That itself will trigger in the future when the quota on a block/pin runs out…
Additionally, the ipfs. subdomain is JWT protected. You either need to login, or get an API key JWT. There will be no freeloading off the API unless thats added as a setting/logic to the API code.
So, the HTTP is more restricted b/c the internet police are more OCD about rouge content on HTTP then the P2P ports, and because the internet is full of trolls, and a quota plugin, idea this year, will enforce limits.
Every integration will do similar things, with public access or gateways being heavily critical against internet freeloading.
I also have no plans to run a kubo or take the liability of running a Lume public gateway any time in the near future. That is a ops, business, and legal headache I don’t need.
A bit unrelated but… I actually don’t have DNSLink support back into the system yet, b/c that requires to have an approval process in place for domains, and because there is no ready protocol plugin yet… But, due to the lesson the community learned around you.hns.siasky.net or siasky.net/X …, and I seeing how Lume’s friends at eth.limo successfully handle subdomain requests, I am being very cautious about non-authorized access…
As for the billing model, I did this in the 1st billing plugin I made, and I think it still makes sense: the usage of each pin will get the cost socialized across all paying users of that pin at the time of access. But the billing is a discussion for another day 
.
So the high level goals become more about asking what web3 (crypto or pure P2P) or web2 protocols are supported, and less about What is Lumes API. Granted, in IPFS I do add some custom endpoints for uploading (POST and TUS), but I comply with the IPFS ecosystem spec as well.
Kudos.
), and so I expect any issues I run into, 