Is it possible to create an api call that supports searching a blog by calendar month?
I'd like to see what account x was posting in sep of 19 I just scroll the calendar back, or shortcut in a search box, to the month and year?
I asked peakd about it and they said it was a core issue.
HAF was designed exactly to allow such api calls to be added easily. In this case, I suspect it could be easily added to the hivemind app.
I don't consider such changes "core changes", nowadays (it's strictly a 2nd layer change), although hivemind was sometimes referred to as a "core app" just because the social media app was considered one of the most critical apps.
I consider "core" everything that is run by full node operators. Right now to run a "full" node the operators have to provide:
We created a simple HAF a few months ago. We have not been able to get any node operators to run it 😔
But I totally agree with you that this is something to integrate directly into Hivemind. As far I've seen it would require at least one additional DB index. Do you think it can be added in one of the next updates?
BTW just opened an issue on GitLab to keep track of this: https://gitlab.syncad.com/hive/hivemind/-/issues/209
We're in the process of simplifying and standardizing deployment of haf apps right now: soon it should be trivial to deploy properly configured ones.
That's great 🙌
Would make everything so much easier for everyone building on Hive.
Keep up the great work.
If we're talking about semantics, I consider hivemind core because it's vital to making most of the front end features work, so even though it's L2, it's as important as core imho. Same logic goes for HAF
That's very true. And if we can tweak HAF a beat to allow such search will be great for a few people who love to connect with old articles and also be able to go straight to some of my old charitable posts and donations.
That's very true. And if we can tweak HAF a beat to allow such search will be great for a few people who love to connect with old articles and also be able to go straight to some of my old charitable posts and donations.
Is it possible to use the escrow feature to sell 'bonds'?
You had said that the second layer can't effect the first.
Can you clarify what that means in terms of making the bonds liquid?
Most recently I've been thinking that complex financial instruments are all better handled at the 2nd layer. In other words, bonds, markets, escrow, etc would all be implemented there. Any link to base layer tokens (if desired) would be done thru proxy tokens issued via some kind of multisig setup.
This 'second layer' would be jsons written to hive and managed largely by 3rd parties?
Is there a technical reason that precludes allowing hive to organically escrow a token created by locking hbd?
A gui would have to be created/incorporated into the existing front ends, but a base layer function that allows me to transfer the token/bond to another account through an escrow feature seems the most elegant way to me.
To have to introduce 3rd party risk would be a deal breaker outside the community being small enough that we can all know each other's reputation for trustworthiness.
Simply creating another H-E type arrangement doesn't solve the 3rd party risk issue, for me.
If there is a technical reason that is a bad idea please state that so I can better understand why we have waited this long for this feature.
1st layer functions don't know anything about 2nd layer stuff. So you can't escrow 2nd layer tokens.
But you can create a 2nd layer escrow function.
You can achieve all functions on the 2nd layer just like on the first layer: it's just a different group of people running different software.
Essentially with 2nd layer, you can run one or more separate "blockchain protocols" with their own rules that just piggy back of the p2p network and transaction ordering functionality of the 1st layer. So the "trustworthiness" of a specific 2nd layer protocol just depends on how that protocol is designed. There's no reason it can't be just as trustworthy as the 1st layer protocol.
Creating this token at 1st layer would slow the chain?
Too much data to be tracked?
It is possible that a malicious update could be successful?
At least for the amount of time it takes to revert the changes?
Keychain would be my example.
I couldn't defend against a malicious update absent the social aspect of hive tipping me off to delete the app.
So with open source distributed nodes keeping everybody honest a 2nd layer is just as secure as hive?
How are you envisioning the functioning of 'bonds'?
A '2nd layer' gui that manages 'bond tokens' according to the contract at the time of escrow?
ie, I stake hbd for a set period of time and receive interest, to liquidate the position I send the token to a 2nd layer contract that executes according to its parameters?