UNIT ACCOUNTING POC #5

New issue

Open

opened 2025-12-22 06:30:26 +00:00 by despiegk · 0 comments

despiegk commented

2025-12-22 06:30:26 +00:00

Owner

Idea is to have a hero_units package to allow early billing & tracking of used capacity.

In an initial POC we can use redis as backend but idea is we will use Unyt from Holochain team later.

draft specs

units: each service is a unit
- e.g. LLM model groq ossgpt 120 is a unit, and then an amount of that unit e.g. tokens used
- e.g. 10 MB of bandwidth used, unit is MB bandwidth, 10 MB is the amount
- e.g. 1h compute VM, VM is min per hour
- e.g. X sec code container: 10 sec compute usage for code container, unit sec, amount 10
these units have unique id's can be different per provider, for id we use SIDs
unit acccounting:
- log in to be defined backend
  - ourtime+ customerid (sid) + unitid (sid) + unitvalue. e.g. customer ah3, unitid: 6ds, amount: 105 , tags: ...
  - do this as a text: | separated
  - key is u64
- this gives us the log of everything which happened
tag: are rather free allows us to record extra details
billing:
- each so often we process all the units, we know till which key (u64) we processed
- we aggregate billing per customerid, to not have to charge to small amounts
- we then create an invoice for the user, we link all the units to it, so user can see the absolute detail
- then we can track if invoice got paid or we got money out of prefunded account
objects
- unitrecord: tracking of capacity (see above)
- user: user of the system identified by SID, has name, email, telnr, description, comments
- account: a user can have multiple accounts, has positions of digital assets e.g. 100 USD, 0.001 BTC, has name
- unittype: sid, description, name (to know which units are known)
- invoice: links to X nr of units which are grouped per account and a date, and payment status
- transaction: when invoice got paid, results in amount going out of account position, details of what happened exactly, which invoice paid, ...
the billing itself units to pricing is done by rhai scripts this is not done in a DB
- the rhai scripts know how to convert units to pricing for that particular customer = account

the service sends unitrecords over mycelium to the tracker

storing of unitrecords

best would be we can already use heroledger: holochain/unyt to track the flow of unitrecords, need to see scalability, and how we can do retention e.g. every X days we make new one to keep it scalable because there will be millions and millions of records flying
if in first phase not doable yet lets look for other possibility e.g. binary blobs stored on seaweedfs, aggregation per e.g. hour per service and then store on seaweedfs

Idea is to have a hero_units package to allow early billing & tracking of used capacity. In an initial POC we can use redis as backend but idea is we will use Unyt from Holochain team later. ## draft specs - units: each service is a unit - e.g. LLM model groq ossgpt 120 is a unit, and then an amount of that unit e.g. tokens used - e.g. 10 MB of bandwidth used, unit is MB bandwidth, 10 MB is the amount - e.g. 1h compute VM, VM is min per hour - e.g. X sec code container: 10 sec compute usage for code container, unit sec, amount 10 - these units have unique id's can be different per provider, for id we use SIDs - unit acccounting: - log in to be defined backend - ourtime+ customerid (sid) + unitid (sid) + unitvalue. e.g. customer ah3, unitid: 6ds, amount: 105 , tags: ... - do this as a text: | separated - key is u64 - this gives us the log of everything which happened - tag: are rather free allows us to record extra details - billing: - each so often we process all the units, we know till which key (u64) we processed - we aggregate billing per customerid, to not have to charge to small amounts - we then create an invoice for the user, we link all the units to it, so user can see the absolute detail - then we can track if invoice got paid or we got money out of prefunded account - objects - unitrecord: tracking of capacity (see above) - user: user of the system identified by SID, has name, email, telnr, description, comments - account: a user can have multiple accounts, has positions of digital assets e.g. 100 USD, 0.001 BTC, has name - unittype: sid, description, name (to know which units are known) - invoice: links to X nr of units which are grouped per account and a date, and payment status - transaction: when invoice got paid, results in amount going out of account position, details of what happened exactly, which invoice paid, ... - the billing itself units to pricing is done by rhai scripts this is not done in a DB - the rhai scripts know how to convert units to pricing for that particular customer = account the service sends unitrecords over mycelium to the tracker ## storing of unitrecords - best would be we can already use heroledger: holochain/unyt to track the flow of unitrecords, need to see scalability, and how we can do retention e.g. every X days we make new one to keep it scalable because there will be millions and millions of records flying - if in first phase not doable yet lets look for other possibility e.g. binary blobs stored on seaweedfs, aggregation per e.g. hour per service and then store on seaweedfs