See part 1 - Explain it to me Simpler
Or jump right to support our DHF proposal
Modules - we are doing these specific things
For your pleasure, we have selected four modules, and broken them down for you to see - "what will be the deliverables" of this "open mithril development framework". I hope you enjoy some of these things:
a. yourFrontend,
b. Auto-Badger,
c. Mithril's FiscalForge on HAF, and
d. Beem Hive-Nectar Python Library
Read on for detailed break downs of tasks we will do over the next year relating to these four modules! With reference to "skematics", I hope you can see that these four modules are "completely separate".
1. yourFrontend
This is our number one champion module that is public right now. Wrap your head around it with this comment:
First we baited out a downvote with perhaps the most worrisome usecase - The Rebel, and gave myself a usecase to show my friends extremely valueable posts (both of them) in a way no other current hive-front-end does - and discussed in detail why true abusers don't actually think their content is valuable.
Then we validated my main theory - that corporations on HIVE need this, since its not professional to show disagreements about rewards.
Since we released it 6 days ago, we already have 2 testers! Sure one is @josephsavage, a close friend and member of our support staff - but consider his interesting use case for his HSBI program on the site https://content.hivesbi.com
This site shows every post that's been upvoted by (whitelisted accounts) one or more of the program's 11 accounts, and shows payouts from just those votes (total delivered program value). This is useful to him, because he can monitor for program health and patterns, possible spam and abuse, as well as find users who might need a bit more love.
Additionally, active user @fjworld asked for iframe integration, and we delivered! He is now testing - https://hive.crypto-dreamr.com, and he can stick that in an iframe right on his main site:
He is working up a document with his feedback - and we eagerly await that!
Notice: we allow your domain, a subdomain of your domain, or we will give you a subdomain of a domain we control, we are currently using crypto-dreamr.com for this purpose. We hope to work with users and leaders to validate many types of use cases for this module!
What we will deliver this year:
A. Simple feature requests through community testing - such as:
- Click heart, show votes in popup.
- TipJar link integration (since it is composeable with blog variables already :)
- More metadata configurations
- Your Requests! We need more testing and experimentation.
B. Robust and configurable support for showing comments/replies on page view:
- Show comments
- Black list / White list users for Show comments
- Order comments
C. Open Source!
Its already built this way as you can see, just the repo is private still:
We will:
- Open the Github repository to the public
- Add a "download .zip" file to allow users to use our composeable settings page to "download a site" while avoiding our microservice.
2. Auto-Badger
This is a very fun and frequently requested automation feature from several members of the community, including many close friends. The badge system by @peak.open is open source, clever, and robust. "just" follow accounts with the badge account and the badge can appear on their profile!
In practice, this quickly turns into project leaders wasting valuable time manually checking, or responding in discord to user pleas to "please update". Many project do update when users request, but struggle to validate in the negative, when users no longer comply with the "stated conditions" of the badge. This is nature, human - and a clear case for easy automation.
We already have one auto-badger working, for @enginewitty's PIMP badge. We will make a front-end to allow users to:
- Define/declare conditions among multiple types of use cases, such as delegations, token holdings, and other conditions requested by the community.
- Create an easy configuration page for projects set their conditions.
- Develop an extremely inexpensive microservice to run automation for them on regular intervals, following users who newly comply with the conditions, and unfollowing users who no longer do.
- Allow users to use our configuration page to "print a script" to run themselves, without paying for the microservice.
We think this app can also do other things, but we would prefer to under-promise and over-deliver. The time we save project leaders from banal tasks such as following and unfollowing with badge accounts - they will dedicate to their project, creating conditions more apt to success for all sorts of project types across HIVE.
3. Mithril FiscalForge on HAF
We have loved the idea of HAF since the beginning. We would use it already, but there is only one public node that we know of, run by the estimable @mahdiyari, and its just not reliable enough for our users right now. So instead, we invented something called a "post-stuffer", where we stuffed every post ever made on HIVE and keep that local to make the backlinker so fast and easy - oh yeah and the T.E.C.. All this will be much easier with HAF.
So, of course we would love to run a HAF node at the first excuse and nuke our post-stuffer - just we need more HardDrive than we currently have to do it. But we have found such an excuse - something on our roadmap that fits: Mithril's FiscalForge. (working title) This is more than "query someone's node", this is "building an app on HAF". We did spend 2 days now reading the manual, and we are open to feedback.
You remember we made the TipJar for HIVE, right? Composeable URL invoices - what a cool low-hanging fruit! With Keychain defaulting to the "main" wallet, its as little as 3 clicks now to pay an exact invoice on HIVE.
Well a follow on concept that we've been talking about is tools for Invoicing, Accounting, and CrowdFunding/Fundraising for HIVE. We could stuff all these things into edge-storage like we do with Whisperbox, but now with HAF - we don't haf to! Faster, better, and more decentralized - here is what we plan to work on:
We will:
Produce a Technical Specification document for Mithril's FiscalForge, a system designed to manage various financial transactions and fundraising campaigns.
The system will comprise three primary components:
--Invoices
--Fundraising campaigns (goal-oriented)
--Fundraising campaigns with perks (tiered contribution model).Run a HAF node
Play with it a bit and integrate calls to our current modules, freeing up disc space for other uses
System Arquitecture: "HAF" (the Hive Application Framework)
-- HAF acts as an event-driven processor, listening for and reacting to custom JSON payloads, which will be defining each invoice/campaign 's parameters and actions.Define the Data structures (custom json)
We will work to define each of the 3 component types above, they might look something like this:
Then we will set up the processing logic:
HAF monitors for custom_json payloads that trigger Create, Update, or Delete (CRUD) operations on the relevant database tables. Concurrently, HAF also monitors transaction records (tx table) for memos containing specific UUIDs that correspond to system entities.
Our current plan (to be refined) looks like this:
Mithril's FiscalForge will utilize a relational database such as PostgreSQL to store/persist such data as described above (invoices, campaigns, contributions, milestones, etc). We will use HAF to generate and execute SQL queries to interact with the database. These queries are triggered by events and data within the system (such as custom json on HIVE!)
Finally - we will look into the recommended approach to building a REST api for this, which is to use PostgREST. With such a "restful" api generated - users can access endpoints using regular/standard methods ("get the data"). At this point we believe this will eliminate (minimize) the need for SQL query construction within the app, potentially simplifying development.
WoW! I think we can do it. What does the app do, again?
And finally - our beloved, top-forked, bespoke fixed and in some ways abandoned friend:
4. Beem Hive-Nectar library
I believe @thecrazygm addressed it quite professionally in our AMA:
"The reason people might think we don't need beem is because its broken and hasn't been updated since 2022. I'm fixing this anyway, because I use it"
Parts of this are already done, see the living "kanban" here. Its being rebranded to nectar now. End of story, and I think this part was appropriately addressed in our original post
What will we do? Read the above post, or scan it over here for our current priority list:
What else might we get done?
We are certainly rigid about being flexible. But, we are confident in committing to the above 4 modules, and the task lists we have associated with them. We will test them, check them, use them, and do more things than are on these lists most probably. And we talked a lot about it in our AMA - so if you haven't already, make sure to give it a listen:
I think there is a module here for everyone. Go ahead and vote on our DHF proposal now - click it here.