Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design and spec out generic billing #62

Open
reidlw opened this issue Apr 19, 2024 · 7 comments
Open

Design and spec out generic billing #62

reidlw opened this issue Apr 19, 2024 · 7 comments

Comments

@reidlw
Copy link
Contributor

reidlw commented Apr 19, 2024

We need to design billing solution that is decoupled from individual operations for which we bill. There is RFC draft here https://www.notion.so/w3sat/Align-on-allocation-client-signal-to-upload-the-bytes-and-billing-with-Blob-3b6fa0373aa444ad98802e492a8f6941

@reidlw
Copy link
Contributor Author

reidlw commented Apr 19, 2024

@Gozala - I'm kind of confused here. Title of this is to design and spec out generic billing. And description links to a notion doc that seems to be specific to making billing work properly going from store/add to blob/*. Then there's a statement at the top of that notion page linking to this merged PR for implementation: storacha/w3up#1342 (review)

So help me unwind... Is there still an issue needed in the backlog here? If so, could you explain a bit more what this is independent from the changes around blob protocol?

@hannahhoward
Copy link

@reidlw I believe the ultimate decision was to implement billing for blobs the same way we do for store/add and not add a generic billing approach. That work is now tracked here: #48

I am guessing this was to do follow on work to really figure out what generic billing, presumably something that we might want in the future related to egress billing (plus other billing -- most platforms like S3 charge per operation), would look like.

@Gozala
Copy link

Gozala commented Apr 19, 2024

Exactly what @hannahhoward said

@reidlw
Copy link
Contributor Author

reidlw commented Apr 19, 2024

@Gozala @hannahhoward - thank y'all for the extra context. I'm struggling to know what to do here. Egress billing is super important but tracked elsewhere. Aside from that I'm not aware of any business driver for major re-working of billing, thus would probably move to icebox for now. WDYT?

@hannahhoward
Copy link

I am inclined to icebox this as a ticket, and see if the design of egress billing indicates the would be an ideal and fast way to implement it, at which point I'd pull it out.

That said, we are going to have to do a lot of intentional design when we introduce pay per operation via crypto, and I wonder if that is the ideal moment to really look at how billing works. (mind you that design work is happening in a month or two anyway)

@hannahhoward
Copy link

long and short, icebox it for now.

@Gozala
Copy link

Gozala commented Apr 19, 2024

I think I would make this part of the egress billing personally, perhaps because I'm more familiar how it works now and know it's not going to work out without putting proper thought into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ice Box
Development

No branches or pull requests

3 participants