We will need a filter function at some point to be able to exclude bot-voted posts from trending and hot. Maybe also create an extra category for those posts. That could make even the tag #steemit interesting to watch again.
That would be good - I did that on my interface but it involves manually updating a "bots list" and periodically checking who has delegated to users on that list. Trying to do it real-time was very resource intensive.
I guess the only performant way is to implement the logic in Hivemind to have it return the data as needed. We won't get around managing a bots list, but I think it wouldn't take that much effort to add new (relevant) bot accounts once in a while.
Best solution would be to have the list stored somewhere on Github (or even inside the blockchain) in an externally reachable text file or so to allow other data services like SDS to consume the same data too.
I guess the only performant way is to implement the logic in Hivemind to have it return the data as needed
I also think that would be the best solution as long as the frontend gets the data from Hivemind. This would also be easy to implement, because the vote rshares from the post data are used for this. This allows the rshares to be assigned to the voters. The filter could then be applied when adding all rshares for the trending and hot score.
to have the list stored somewhere on Github (or even inside the blockchain) in an externally reachable text file
The bot list on Github would certainly be easy to solve. A readable list on the blockchain would be more challenging. I don't have any ideas about that now...
A readable list on the blockchain would be more challenging.
I don't think that would be hard. Someone could make a dedicated account and store the list in custom_json operations whenever there's an update, then the front-end could just check the account history.
More challenging would be to decentralize the updates using some logic like Twitter's "Community Notes" logic so that no single person would need to maintain it. That would require some sort of UI software and a more robust protocol for the custom_json ops, and the front-end would have to scan the entire blockchain for updates. Obviously, hivemind would be better for that purpose, but I don't know how likely we are to get traction for hivemind updates.
the front-end could just check the account history.
This would be too late in the front end. The entire calculation would then have to be performed again and the order queried again... Hivemind is already the right choice, as the relevant score is already calculated there.
A custom_json operation would have the advantage that no additional API requests would be required, as certain custom_json operations are processed by Hivemind anyway. However, like you, I see the effort involved in securing this handling against "attacks" or only accepting it from a specific account (for example @steemitblog). Then there is the question of where/how Hivemind stores the data.
But quite feasible...
dedicated account
This leads me to the thought that there is/was something similar for beem. The account @fullnodeupdate contains (in its profile) data about RPC nodes and their performance. Unfortunately, these are no longer updated on Steem. However, this alternative also requires further checks to ensure reliability.
Ergo: Changing the score calculation with a static (code-based) list should not be difficult. However, the implementation of a dynamic list must be chosen wisely. We will have to discuss this further.
Yeah, I was thinking that the front-end would refresh the list once an hour or once a day or something like that. Not to check it, interactively, while processing the feed.
The filter could then be applied when adding all rshares for the trending and hot score.
Yes, that's exactly how I thought we could solve it. The existing trending and hot algorithms could still be used and the botted rshares would just get subtracted before calculating the score with the total rshares left.
This would also be easy to implement ...
I've heard something like @the-gorilla doing holiday and you solving it in Hivemind and taking his 30 SBD daily for a while... ^^
I like it when you and @moecki use words like "easy" when discussing something that I've not looked at how to do yet ๐
I've heard something like @the-gorilla doing holiday and you solving it in Hivemind and taking his 30 SBD daily for a while... ^^
@moecki - I'd welcome a break (not for too long though ๐) if you'd like to take over for a bit (or split the work time). Ping me on Discord if you think that you've got time ๐
Nice suggestion :-)
I have a few days holiday now. Then we'll talk about it again...
Considering the still open bookmark PR, I don't know if a new one makes sense at all. But maybe there is a chance that it will draw a bit more attention to it again. :-)
Considering the still open bookmark PR, I don't know if a new one makes sense at all.
It's always about priorities. As one can already bookmark links with ctrl+d in most browsers and even sync them between different devices when registering an online account (for example, using Firefox Sync in case of Mozilla browsers), the priority for the bookmark PR will not be as high as something like improving the trending/hot overviews on steemit.com, which is a very much wanted feature for many users.
We will need a filter function at some point to be able to exclude bot-voted posts from trending and hot. Maybe also create an extra category for those posts. That could make even the tag #steemit interesting to watch again.
Da gab es mal einen Ansatz :) #BBBS
https://steemit.com/hive-127586/@peppermint24/s5ix2c
That would be good - I did that on my interface but it involves manually updating a "bots list" and periodically checking who has delegated to users on that list. Trying to do it real-time was very resource intensive.
Do you have a better idea on how to do that?
I guess the only performant way is to implement the logic in Hivemind to have it return the data as needed. We won't get around managing a bots list, but I think it wouldn't take that much effort to add new (relevant) bot accounts once in a while.
Best solution would be to have the list stored somewhere on Github (or even inside the blockchain) in an externally reachable text file or so to allow other data services like SDS to consume the same data too.
I also think that would be the best solution as long as the frontend gets the data from Hivemind. This would also be easy to implement, because the vote rshares from the post data are used for this. This allows the rshares to be assigned to the voters. The filter could then be applied when adding all rshares for the trending and hot score.
The bot list on Github would certainly be easy to solve. A readable list on the blockchain would be more challenging. I don't have any ideas about that now...
I don't think that would be hard. Someone could make a dedicated account and store the list in custom_json operations whenever there's an update, then the front-end could just check the account history.
More challenging would be to decentralize the updates using some logic like Twitter's "Community Notes" logic so that no single person would need to maintain it. That would require some sort of UI software and a more robust protocol for the custom_json ops, and the front-end would have to scan the entire blockchain for updates. Obviously, hivemind would be better for that purpose, but I don't know how likely we are to get traction for hivemind updates.
This would be too late in the front end. The entire calculation would then have to be performed again and the order queried again... Hivemind is already the right choice, as the relevant score is already calculated there.
A custom_json operation would have the advantage that no additional API requests would be required, as certain custom_json operations are processed by Hivemind anyway. However, like you, I see the effort involved in securing this handling against "attacks" or only accepting it from a specific account (for example @steemitblog). Then there is the question of where/how Hivemind stores the data.
But quite feasible...
This leads me to the thought that there is/was something similar for beem. The account @fullnodeupdate contains (in its profile) data about RPC nodes and their performance. Unfortunately, these are no longer updated on Steem. However, this alternative also requires further checks to ensure reliability.
Ergo: Changing the score calculation with a static (code-based) list should not be difficult. However, the implementation of a dynamic list must be chosen wisely. We will have to discuss this further.
Yeah, I was thinking that the front-end would refresh the list once an hour or once a day or something like that. Not to check it, interactively, while processing the feed.
Yes, that's exactly how I thought we could solve it. The existing trending and hot algorithms could still be used and the botted rshares would just get subtracted before calculating the score with the total rshares left.
I've heard something like @the-gorilla doing holiday and you solving it in Hivemind and taking his 30 SBD daily for a while... ^^
I like it when you and @moecki use words like "easy" when discussing something that I've not looked at how to do yet ๐
@moecki - I'd welcome a break (not for too long though ๐) if you'd like to take over for a bit (or split the work time). Ping me on Discord if you think that you've got time ๐
Nice suggestion :-)
I have a few days holiday now. Then we'll talk about it again...
Considering the still open bookmark PR, I don't know if a new one makes sense at all. But maybe there is a chance that it will draw a bit more attention to it again. :-)
It's always about priorities. As one can already bookmark links with ctrl+d in most browsers and even sync them between different devices when registering an online account (for example, using Firefox Sync in case of Mozilla browsers), the priority for the bookmark PR will not be as high as something like improving the trending/hot overviews on steemit.com, which is a very much wanted feature for many users.
I hope that you're having a nice holiday ๐