See part 1 - Explain it to me Simpler
Or jump right to support our DHF proposal
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".
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 
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 
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!
A. Simple feature requests through community testing - such as:
B. Robust and configurable support for showing comments/replies on page view:
C. Open Source!
Its already built this way as you can see, just the repo is private still:
This is a very fun and frequently requested automation feature from several members of the community, including many close friends. The badge system by 
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 
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.
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 
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:
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.
And finally - our beloved, top-forked, bespoke fixed and in some ways abandoned friend:
I believe 
"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:
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.
