-
Notifications
You must be signed in to change notification settings - Fork 0
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
Goal: Billing #166
Comments
@KwilLuke @brennanjl do you guys already have it in place? |
This is currently implementable with oracles and extensions. Once Truflation is ready to add this as a feature, we're happy to jump in to help prototype, show how it can be done right now, and then make additions to the Kwil product as needed. Ideally, it follows a process similar to how we have handled streams, where:
|
@brennanjl please point me to the documentation, if any. Thank you! |
@zolotokrylin you can check out the docs for oracles and extensions here: https://docs.kwil.com/docs/extensions/oracles-overview There is also an example for an eth oracle here: https://github.com/kwilteam/kwil-db/tree/main/extensions/listeners/eth_deposits For Truflation's billing, the implementation would require some creativity to get data payment rails into an extension. For example:
Lot's to think through here, but have a look at the docs and let us know if this looks interesting for what you are thinking. |
Yeah, we do not yet have a place describing how to do pricing per-se; it would likely be a framework we develop via extensions. If you have an outline on requirements, I can try to propose more specifics on a solution. |
Thank you, guys! I pinged @itscameronlee to provide us the initial input directly in the Spec doc (see description of the issue). |
@itscameronlee a kind reminder to provide initial inputs here. |
Will do. Assigning to myself so I don't lose track of this. |
Notes from our meeting on 18th of June, Billing begins centralised and simple. Once a user subscribes via the existing billing mechanism,
Side note on Trust: @zolotokrylin - did you wish to add to this? |
@rsoury thank you for your message.
Not in the first version, but eventually that's the end goal. |
@rsoury could you please propose a high-level system in the Spec doc (see description of this issue)? |
We have a start on a technical spec internally, will be incrementally added to the doc today/tomorrow. |
This comment was marked as resolved.
This comment was marked as resolved.
@rsoury I have replied in the Specs doc. |
@zolotokrylin - We've made a good start to this spec. |
@truflation/team-tsn-core I have left comments in the doc. |
@zolotokrylin - Replied. Will leave my https://calendly.com/ryansoury/chat here too. |
@rsoury booked the meeting for tomorrow. |
We had a call with @rsoury . We are aligned on how to proceed further. He will share the recording of our meeting here. Next sequential steps:
|
@truflation/team-tsn @truflation/team-tsn-core - Please review the Spec and share any thoughts or questions. Once reviewed, please confirm awareness and alignment on the Spec. To review the meeting: |
I just left an additional comment in the document, @rsoury. |
Replied @zolotokrylin @Jarryd-pretorius @outerlook |
@zolotokrylin - Discussed with @Jarryd-pretorius , and we will use Supabase as the core database. No intermediary cache is necessary. Furthermore, no SQS or event management is necessary, as I realised it to be easier to just consolidate all metadata updates across Truflation streams within the TSN. Vadim, and @outerlook - Please review the latest architectural update. |
@MicBun @outerlook do you need other members participating to this goal? If not please unassig them and leave only those who are directly involved. Thank you! |
Good job guys on the progress of this goal @MicBun @outerlook. 👍 What do you think is the ETA for completion? Do you have any blockers that need to be escalated? |
Hi @markholdex, there are two major blockers for now:
which block tasks related to it as:
Includes the wait for the blocker to be cleared, I think 3 weeks. It can be as fast as 1 week if it cleared, as most of the functions and methods are set up and then we can sync with the established Supabase database. |
See that #383 is important just to see how much data our subscribers are consuming, as we're not using any kind of usage cap it won't modify the permission logic right now. Said that, if you want to split that analytics step into another goal, the billing logic wouldn't be affected. This is just a suggestion in case other goals can take priority here. |
Yes, please. Let's split so we can already have a basic billing released and start playing with it. |
@outerlook how about @MicBun comment #383 (comment) to match our specs document and track the Of course, we can split the specs into multiple versions and extend the billing to support later a |
The comment is valid, but is inserted in more context here:
as for the intention of already tracking some metrics is about this part:
So, the need for the metrics to be there is knowledge about consumption, for us to start checking how we will eventually set gas-based billing. I.e., if we release it and someone with a subscription spams requests, we won't know easily this is happening from a single user or even how they truly use it. But my suggestion is to be ok with that for now, just to focus on other goals |
@outerlook alright, I'll convert into a Goal |
I executed a test to see if it works:
|
This comment has been minimized.
This comment has been minimized.
TSN pages are loading now. I will proceed and change the wallet address and test if the billing access is working. https://truflation.com/dashboard?feed=us-inflation-rate&tsn=true |
All work with the new wallet address. Good job @outerlook and @MicBun |
Specs
Blocker
Related
Problems
To decide
Problem: truflation/tsn-synchronizer repo is not created(cancelled)Billing/Data provider tasks
TSN Tasks
Supabase tasks
Website tasks
The text was updated successfully, but these errors were encountered: