hive issueshttps://gitlab.syncad.com/groups/hive/-/issues2023-07-14T10:49:32Zhttps://gitlab.syncad.com/hive/haf_block_explorer/-/issues/52Block Explorer GUI rebuild2023-07-14T10:49:32ZJakub LachórBlock Explorer GUI rebuild## Why we need to rebuild the whole GUI?
At the very beginning, I must agree that the iteration approach is a much better way of writing software than a full rebuild. But the current state of code is unacceptable, and for now we will lo...## Why we need to rebuild the whole GUI?
At the very beginning, I must agree that the iteration approach is a much better way of writing software than a full rebuild. But the current state of code is unacceptable, and for now we will lose much more time trying to do anything useful with that state of code than just making the whole thing from scratch.
The list of issues with the current state of the code, after my audit:
1. Lack of typescript. If we want to painlessly manage the data from the API, we have to prepare proper interfaces and types and structuralize the communication between components.
2. Too many dependencies. I saw almost 30 dependencies in NPM, around 10 of them were dead, but still, it's (more or less) 20 dependencies in use. Most of them can be fully replaced by JS features or better tools.
3. On the FE team, we decided on our basic technology stack, which is React + Next.js + Typescript + Tailwind and Shadcn UI (for style). Block Explorer uses only React from that list, and for other tasks – different tools. In my opinion, it's better to keep our infrastructure similar across other projects.
4. No config. Right now, all API calls addresses are hardcoded in many methods. To use Block Explorer with different BEs, I had to modify 8 files. It's unacceptable.
5. Calculations are done in an unsafe way. In the future, we'll try to avoid doing any math in FE's utils. Right now they are without any docs or comments, with strange hardcoded values and unsafe JS operations that may easily produce wrong results in decimal's precision.
6. A lot of pointless utilities like getting +1 blocks, clearing filters, etc. All of that may be handled by better components.
7. Using too many HTML tags. Like having `<StyledTableCell>` in one page declared (not called, declared) 36 times!
8. Lack of the generic code. The components are too specific and, despite having almost identical functionalities, are completely separate. Instead of using generic cards and tables, all are written for specific views.
9. ...but at the same time, the style is shared across them! Specific tables use the style of other tables!
11. The data flow across apps is a mess. Most of it is distributed by useContext, some by props, but without any clear logic in that. More in the next points:
12. There is no one, reliable entry point for API data. Right now, the calls are started in useEffects across pages, presentational components, and in useContext. When looking from a distance, any component may be the first source of data, which makes providing it too chaotic to divide it into variables and provide it across smaller components clearly.
13. Context is overused when, in most cases, props are obvious solutions (and better).
14. There is no clear separation between getting data, handling it for FE's purposes, and saving it. And the chunks written to states are too big. That's another thing to fix with the new API later.
15. Because of the lack of Typescript it's very difficult to know what presentational components are needed.
There are more minor issues, but the list above is the greatest reason for me to propose a complete rebuild. I think it's necessary for future upgrades in that project to create a solid structure that is easy to manage and follow. And let me tell you, this is a rather small app. It has 7 different pages and a few components for display. We don't need to handle user accounts, complicated forms, or input. That's why it should be possible to recreate it in a relatively short time.
## The plan
I'll create more detailed descriptions for separate issues later. Here is only the general plan:
1. Create a new Next.js React app. Configure it.
2. Add and configure the necessary style dependencies.
3. Create `FetchingService` for making a generic structure for API calls. The shape and full functionality of that service isn't fully known yet, but with the current number of endpoints, it won't be complicated at all.
4. Create a basic layout and parent component for app.
5. Remake all the previous pages. Prepare types and interfaces for everything that should be displayed there. Plan the necessary child components.
6. Add useContext and providers to the app for every case, when some data needs to be reusable across pages.
7. Import presentational components from Shadcn UI and use them to recreate old views in pages.
8. Add simple utils to the component. If something is more complicated or should be used across many pages, move it to a common file.
9. Start restyling everything, from the recreation of the previous one to something a little nicer.
10. If at any level of preparing the app, we see that we need some API upgrades, we'll create an issue for the BE's team. Keep in mind that API can be adjusted for our requirements.
11. In the meantime, fix the obvious issues written in Gitlab, if they can be fixed in existing views without adding big functionalities.
After all that, we should have fresh, clear code and a working Block Explorer. Then we can do a lot of upgrades to the application, and with a solid base, I believe it will work for a long time.
I'll divide the work between me and @pberezka. Because most of that is on separate pages in separate contexts, it shouldn't be a problem at all to divide it between two people. Of course, we'll be in touch with the rest of the team.Jakub LachórJakub Lachórhttps://gitlab.syncad.com/hive/hive-io/-/issues/17Next round of improvements2022-12-08T17:45:43ZRKNext round of improvements- Need to fix those keywords
- Need to add music category to eco page
- Can try and set the wallet page to a 3 x 3 grid, not sure if will look better
- Ledger logo would need an update when designer is available to create new one- Need to fix those keywords
- Need to add music category to eco page
- Can try and set the wallet page to a 3 x 3 grid, not sure if will look better
- Ledger logo would need an update when designer is available to create new oneRKRKhttps://gitlab.syncad.com/hive/hive/-/issues/325Create vop for proposal creation costs2022-08-29T15:44:56ZMarkyCreate vop for proposal creation costsWhen creating a proposal, there is no transaction history of the fees involved. Many users are not aware of the costs for 61+ day proposal and there is no way to look on chain history to see what was spent on proposals. HBD just disapp...When creating a proposal, there is no transaction history of the fees involved. Many users are not aware of the costs for 61+ day proposal and there is no way to look on chain history to see what was spent on proposals. HBD just disappears from account with no trace.https://gitlab.syncad.com/hive/wallet/-/issues/39Keychain for everything?2022-04-23T22:12:31ZMahdi YariKeychain for everything?In wallet when you have logged in with posting key, you can claim the rewards just fine. But when you have keychain on your browser, wallet forwards that to the keychain when it shouldn't because you already have the posting key.
Keyc...In wallet when you have logged in with posting key, you can claim the rewards just fine. But when you have keychain on your browser, wallet forwards that to the keychain when it shouldn't because you already have the posting key.
Keychain shouldn't be the default option for actions in the wallet. Every thing pops up the keychain by default.
Even when you have logged in with posting key.
It should be possible to do the transaction in other ways too.https://gitlab.syncad.com/hive/hive/-/issues/246Test p2p code changes inside mirror testnet2022-05-15T17:41:26ZDan NotesteinTest p2p code changes inside mirror testnetCurrently the changes required to speedup p2p performance have only been tested on the mainnet. Since most of the mainnet nodes are not running the faster new code, there could be a problem that will only be exposed when all the nodes in...Currently the changes required to speedup p2p performance have only been tested on the mainnet. Since most of the mainnet nodes are not running the faster new code, there could be a problem that will only be exposed when all the nodes in a network are running with the new code. To ensure this is not the case, we need to run a testnet that only has "new p2p" nodes.
Some scenarios to verify:
- [x] All nodes on mirror testnet, running new code, in live mode
- [x] Introduce a new node to above network that needs to sync from scratch (time the performance as well)
- [ ] Setup one or more of the nodes as API nodes and load them with API traffic
- [ ] Sync a node with sql_serializer (time the performance as well)
- [ ] Test nodes operating under live mode, temporarily fork the network (i.e. create a situation where two or more sets of nodes have lost connectivity to the other sets), and ensure the "best fork" wins
- [ ] Introduce a syncing node to the above scenario and ensure it successfully chooses the correct fork
Other metrics of interest in the above scenarios: cpu% percentage consumed by both p2p and write_queue threadsMarcin SobczykMarcin Sobczykhttps://gitlab.syncad.com/hive/wallet/-/issues/38Bad tab title: Missing translation: en.header_jsx.steem_proposals2022-02-22T16:16:16ZDan NotesteinBad tab title: Missing translation: en.header_jsx.steem_proposals![image](/uploads/7b953b733f00d6612f682e8f34453dfc/image.png)![image](/uploads/7b953b733f00d6612f682e8f34453dfc/image.png)https://gitlab.syncad.com/hive/hive/-/issues/232Try to create a test that duplicates increase in block time offset under heav...2024-03-27T18:35:30ZDan NotesteinTry to create a test that duplicates increase in block time offset under heavy transaction load on networkPost 1.27.5https://gitlab.syncad.com/hive/hive/-/issues/231Allow setting the recovery account when creating an account2022-01-31T17:21:47ZHowoAllow setting the recovery account when creating an accountHowoHowohttps://gitlab.syncad.com/hive/hive/-/issues/223Make RC plugin less noisy2022-05-27T12:40:46ZGandalfMake RC plugin less noisyRC plugin currently emits tons of spammy messages during the replay, such as:
`Accepting transaction by alice, has 1 RC, needs 2 RC, block 3, witness bob.`
Quick solution is to make it go to the debug log.
Another thing is do we reall...RC plugin currently emits tons of spammy messages during the replay, such as:
`Accepting transaction by alice, has 1 RC, needs 2 RC, block 3, witness bob.`
Quick solution is to make it go to the debug log.
Another thing is do we really need to check on RC during replay?
That's plenty of checks that were done before, and non consensus anyway.Andrzej LisakAndrzej Lisakhttps://gitlab.syncad.com/hive/haf/-/issues/33reindex dumper: remove lock when third batch of blocks arrive when first is n...2022-02-01T16:49:44ZMarcinreindex dumper: remove lock when third batch of blocks arrive when first is not fully processed yetthe problem is with [data_processor class](src/sql_serializer/data_processor.cpp) and its triggering:
1. when the data_processor is triggered first time it moves cached data to internal member `_dataPtr` what immediately triggers the thr...the problem is with [data_processor class](src/sql_serializer/data_processor.cpp) and its triggering:
1. when the data_processor is triggered first time it moves cached data to internal member `_dataPtr` what immediately triggers the thread to move the data from `_dataPtr` to stack variable `dataPtr` and start to processing it
2. when the data_processor is triggered second time and previous batch was not finished yet, the again new cached data are moved to member `_dataPtr`, bu because previous data are not process yet the thread was not triggered
3. when the data_processor is triggered third time and the first batch was not finished yet, then the trigger function will stuck on the mutex:
```
dlog("Trying to trigger data processor: ${d}...", ("d", _description));
std::lock_guard<std::mutex> lk(_mtx);
_dataPtr = std::move(dataPtr);
```
This stuck on mutex should not happen, instead new batch of data should be queued to process by the thread and immediately return to do not hold the trigger callerhttps://gitlab.syncad.com/hive/haf/-/issues/32rename `hive.end_massive_sync` to `hive.end_batch_of_blocks`2024-01-02T21:21:28ZMarcinrename `hive.end_massive_sync` to `hive.end_batch_of_blocks`Moreover it would be good to rename `MASSIVE_SYNC` event to 'CONSISTENT_BLOCK` or something similarMoreover it would be good to rename `MASSIVE_SYNC` event to 'CONSISTENT_BLOCK` or something similarMarcinMarcinhttps://gitlab.syncad.com/hive/hivemind/-/issues/173Recover a lost community owner account.2021-10-28T14:33:08ZPablo GarciaRecover a lost community owner account.They authority keys of a "popular" hivemind community owner account can be lost.
Without this account it is NOT possible to update the settings of a community, set new roles, etc.
To solve this it shall be allow to some community membe...They authority keys of a "popular" hivemind community owner account can be lost.
Without this account it is NOT possible to update the settings of a community, set new roles, etc.
To solve this it shall be allow to some community members/roles - such as admins - to change the owner account of a community if some criteria is fullfilled:(a) Period of inactivity of the owner account (b) 75% of community admins agree on the update, etc.HowoHowohttps://gitlab.syncad.com/hive/hivemind/-/issues/170Add a notification if a post/comment has beneficiaries to a user2021-09-29T18:47:59ZHowoAdd a notification if a post/comment has beneficiaries to a user`receive notification when someone adds you as benefactor for a post reward? ``receive notification when someone adds you as benefactor for a post reward? `HowoHowohttps://gitlab.syncad.com/hive/jussi/-/issues/4better logging control and better logging needed2021-05-02T17:13:28ZGandalfbetter logging control and better logging needed```
{"e":"KeyError('accounts_blacklist',)","jid":"000820282724845709","event":"using empty accounts_blacklist","logger":"jussi.validators","level":"warning"}
```
such messages should go away to debug level
etc.```
{"e":"KeyError('accounts_blacklist',)","jid":"000820282724845709","event":"using empty accounts_blacklist","logger":"jussi.validators","level":"warning"}
```
such messages should go away to debug level
etc.https://gitlab.syncad.com/hive/hivemind/-/issues/159hive server is too talkative2024-03-27T03:28:04ZGandalfhive server is too talkativeDuring usual "production" use case, `hive server` shouldn't be that talkative as it generates huge amounts of mostly useless logs, not to mention that such extensive logging tends to have non-negligible impact on performance.
Make such v...During usual "production" use case, `hive server` shouldn't be that talkative as it generates huge amounts of mostly useless logs, not to mention that such extensive logging tends to have non-negligible impact on performance.
Make such verbosity optional.JulyHivemindhttps://gitlab.syncad.com/hive/hive-whitepaper/-/issues/5Section 3.2 and 3.3 have reverse introduction of witnesses2021-02-18T07:40:41ZRKSection 3.2 and 3.3 have reverse introduction of witnessesSections should be reversed or rewritten.
3.2: "Hardforks and key protocol changes are accepted by 17 out of 20 consensus witnesses."
3.3: "Blocks are produced at 3 second intervals and are signed by “Witnesses” selected based on the...Sections should be reversed or rewritten.
3.2: "Hardforks and key protocol changes are accepted by 17 out of 20 consensus witnesses."
3.3: "Blocks are produced at 3 second intervals and are signed by “Witnesses” selected based on the total weight of the
Hive Power supporting them through individual approvals."
Introduction of witnesses doesn't look right.
_Issue recorded for revisiting next update opportunity._RKRKhttps://gitlab.syncad.com/hive/hive/-/issues/115Add a cutoff amount for a proposal2021-04-21T22:52:56ZHowoAdd a cutoff amount for a proposalDiscussed in https://gitlab.syncad.com/hive/tasks_without_projects_yet/-/issues/30Discussed in https://gitlab.syncad.com/hive/tasks_without_projects_yet/-/issues/30HowoHowohttps://gitlab.syncad.com/hive/hivemind/-/issues/122API: Query JSON Metadata2021-05-17T21:30:01ZtherealwolfAPI: Query JSON MetadataI've talked about this with @dan shortly before and the idea is to be able to store data within the users JSON meta-data and being able to query it directly.
*Example:*
My app has a user with id `123` and the user connects a Hive accou...I've talked about this with @dan shortly before and the idea is to be able to store data within the users JSON meta-data and being able to query it directly.
*Example:*
My app has a user with id `123` and the user connects a Hive account and adds `appId: 123` to the meta-data. I'm then able to query metadata via API to get hive account where `appId` within `json_metadata` or `posting_json_metadata` equals `123`.
API structure would be:
```
type KeyType = 'posting' | 'active'
queryJsonMetadata(
key: string,
value: string,
type: KeyType | KeyType[]
): HiveAccount | HiveAccount[]
```
Raw SQL is something like
```
SELECT * FROM "users" WHERE CAST ("posting_json_metadata" -> key AS STRING) = value
```
Would be great if this could get a somewhat high priority as certain features within my app depend on this API functionality.https://gitlab.syncad.com/hive/wallet/-/issues/10Warn user before sending transfer with memo prefixed with #2022-07-19T12:05:03ZarcangeWarn user before sending transfer with memo prefixed with #When a user wants to send an encrypted memo with a transfer, he/she prefixes the memo with the '#' character.
But if the user has not logged in using his/her memo key, the memo is not encrypted and sent in clear text.
A warning should b...When a user wants to send an encrypted memo with a transfer, he/she prefixes the memo with the '#' character.
But if the user has not logged in using his/her memo key, the memo is not encrypted and sent in clear text.
A warning should be issued to inform the user that
- his/her memo will not be encrypted if going further
- he/she should logoff and login again using his/her memo key (or perform any easier action to do so)https://gitlab.syncad.com/hive/condenser/-/issues/55Wrong redirection after deleting a comment2020-05-08T21:21:14ZBenjamin FuksWrong redirection after deleting a commentAfter deleting a comment, one is redirected to the deleted comment itself. As the comment does not exist anymore, this results in a 404. I suggest to redirect to the parent post instead.After deleting a comment, one is redirected to the deleted comment itself. As the comment does not exist anymore, this results in a 404. I suggest to redirect to the parent post instead.