Our Champion Modules - be Specific (part 2)

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:

image.png

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.

image.png

Additionally, active user @fjack 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:

FirstTestFJack.png

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:


image.png

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:

  1. Define/declare conditions among multiple types of use cases, such as delegations, token holdings, and other conditions requested by the community.
  2. Create an easy configuration page for projects set their conditions.
  3. 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.
  4. 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:

image.png

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:

image.png

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:


image.png

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.

Freedom and Friendship

0.46985888 BEE
5 comments

I like the auto badger!
untitled.gif

0.00123741 BEE

I love it as a brand!

And when we talked about the schematics yesterday, this thing could become a HIVE-user favorite. I mean, just think about what else we could do with an "auto-follower system". (don't forget to think laterally!)

0.00000206 BEE

The Auto Badger idea is actually pretty cool. Automating badge updates saves project leaders a lot of time and I can see how that would make managing communities way easier

0.00120069 BEE

The auto badger, look cool.

!ALIVE
!PIZZA

0.00112429 BEE

low key, might be the coolest one. But we had to commit to some hard stuff, so we decided to only half reveal its true power, just in case. Already people are wondering how we will get it all done :)

0.00000000 BEE

Hi, thanks for the more detailed insight into your proposal here.

Frontend: Are you aware that Ecency has already put significant resources into the Breakaway community system - in association with SPK - that effectively enables anyone to run their own custom and open source version of Ecency?

Maybe you can explain why Frontend is needed in light of the funding for Ecency's breakaway project?

Invoicing: In the same vein, are you aware that there are already multiple systems that deliver invoicing on Hive? There's keychain Store for mobile (funded via keychain DHF) and also Hive Debit the upcoming debit card system. Plus also V4V.

So is there a need for another system that does similar?

I think one of the biggest annoyances I have with the development on Hive is that there is so much duplication. I can't think of any important feature that doesn't have at least 2 teams working on it in competition with each other - sometimes with both teams being funded. I appreciate that some people think that competition is good, but I think any benefit like that is lost when both are being funded regardless of success - since there is no commercial aspect.

I think you should probably rethink the problems you are aiming to solve.

It seems like the biggest problem from a development standpoint is the total lack of standardisation. This has led to a situation where almost all developers think that the code provided by other developers isn't worth using or high enough quality. If you could specify a coding standard system and modularisation/plugin system for Hive (not a simple task) then that would be the ultimate win from my POV. An example of what I'm talking about is the plugin system used in the Elgg open source social networking framework.

Cheers

0.00000000 BEE
(edited)

Great feed back! Both of your examples - these modules are SIGNIFICANTLY different. That shall be my next post.

Especially ecency/breakaway i answered in the AMA, but good to write it out. This is a rapid deploy, show less front end. Not a place to write posts, is the simplest way to say it.

Not even a competitor. In fact, im talking with @starkerz about helping him with breakaway communities. Thats not a part of this proposal though.

Appreciate you - I can't unsee what I see, or unknow what I know. I need this feedback. I know it feels shilly, heck, I feel shilly. And someone said I should do it for a year of drips! LOL, would kill me.

But, you are appreciated!! For this, and in public!

0.00000000 BEE

Also, i must emphasize - i am not looking for work. I appreciate links, i do read and collect them. I will and would do many things, collaborate with all.

I have starred skatehive, ecency/breakaway, and many other repos in this journey. Breakaway will need a B2B rapid deploy module, in my estimation. Similar to other things we are doing (redhat style). Our model is sound.

This isnt some rando look for work proposal. Its a roadmap of things that need doing. And Im getting feedback!

0.00000000 BEE

We use keychain stuff for nearly everything; SpendHBD, possibly distriator and definitely HiveDebit will be using our HAF api for sure.

There is a disconnect, anyway, tomorrow is another day, another post. Blessings!!

0.00000000 BEE

PIZZA!
Hive.Pizza upvoted this post.

$PIZZA slices delivered:
@edgerik(1/15) tipped @ecoinstant

Moon is coming

0.00000000 BEE