You are viewing a single comment's thread from:
RE: App/feature Request: Filter the New feed
Here is a GitHub issue for it. Problem is that it isn't as easy as it sounds. We offered a $300 SBD bounty just to do a part of it, and it went unclaimed. I think Steemit is planning to do it, but it is something that won't be done until communities and a few other things are done first.
From helicopter view it is more or less to create a frontend such as customer care people use for messaging/chatting type of services based on using SQL type of queries. I have no idea how this works in the blockchain as DB, since any SQL type of query can have performance impact. I only know that with 20 years experience in high end IT and telecommunications industry and solutions, I was selling a product that just did that!
The same product had also instance reporting through pre-aggregation of parameters, and we had a whole bunch of those parameters in a multi dimensional DB to allow all sort of cross views/reporting. The pre-aggregation was there to create the instant response on a report request. OLAP technology was used. The difficult part of the product was the data loader, ie the data stream from the core engines (te messaging engines, such as SMS, MMS, RCS) towards this customer care and reporting product, since it needed to support 10.000 - 50.000 tx/sec (and under race track conditions (ie no hardware failures) up to 100.000 tx/sec), and we succeeded in creating this. We had this tool separate from the core messaging engines for the obvious reason that the processing required for data loading, data aggregation and the SQL queries for customer care shall not have impact on the performance of the core messaging service.
Relating this back to blockchains (just a DB again in my helicopter view again), you want to create a copy of the blockchain and perform these type of tasks offline from the core blockchain that needs to totally focus on speed of transactions. If somehow the blockchain is sooooo superfast it can handle everything on the same blockchain, go for it, but I would say: try to find another solution since transaction speed is super super important for scale.
NOTE: I'm not a software architect, I'm also not a software designer so my suggestions above shall be taken with precautions; However the information I provided can be taken as real and correct.
Note: 300 SBD bounty? Seriously? If you want a good working system being able to handle proper performance, this will cost factor of 100s more! If you just want to have the functionality but no performance at all, maybe 300 SBD or lets say factor of 10 (ie 3.000 SBD) could be sufficient
Yes, that is a good explanation. Basically what they need to do is have a daemon that processes the blockchain transactions and puts them into something that can be easily and efficiently queried (like a SQL database). I agree that it would be expensive to get someone to develop - which goes along with what I was saying as far as it not being something that can be quickly and easily done. It is a very useful feature, and it is something that can be done, but it is going to take time/resources to complete.
I'm in the business of mission critical software with super performance, and about 5% of all software engineering effort is writing the code lines. Rest is making sure the system is stable and FAST! any software engineer can make marketing software, ie functionality only, but when it comes to performance and stability, then software architecting and engineering is a whole different beast.
EDIT: btw, No SQL DB seems to become more popular. Also DB technologies from Facebook and Google are super super fast, Cassandra. But even LDAP is very fast, at least in reading, not so much in writing. For proper tools, already DB selection is super important. DB expert is required. Than an software architect (usually not the same person, or you have one of those superman software architects).
I am actually in a similar industry :)
Than you know all what I mean :) But, I'm (just) a product manager and sales guy hahahaha...but love to work with software architects :)
The original proposal in the bounty was to use ElasticSearch
I have no idea what ElasticSearch is. To be honest, our search capabilties s*cks and that is Google search. It does not load last day or two so. Furthermore, search in own post and comment history is not possible, I think Google does not look into comments, but did not play around with to much. That basically means, a lot extra time for posters to use something already written in the past. So inconvenient. Also even Chrome is too slow in get the next batch of 20 posts, that is why in my view most posts at position 80 or 100 in one of the general channels get lost for everybody. Hence, the gamers in the community will seek optimal time to post to get most rewards etc. This really needs to change to get retention of a lot more users.
EDIT: comparison between ElasticSearch and Cassandra, didn't read it yet myself: http://stackoverflow.com/questions/27054954/elasticsearch-vs-cassandra-vs-elasticsearch-with-cassandra
I do agree it is a very important feature! I was the one who wrote the GitHub issue, and organized the bounty to try and get it done :)
To be honest, I would love to have a desktop App, that keeps posts loaded in history. Also local search can be much faster than through remote server and browser. Also, more local means much less load on the servers, requiring less hardware, hence costs. But hey, I'm a local software guy; Love Apps on my Smartphone much more than WebApps and so on.
Ah, thanks for that. I know nothing about development, but I see it already there in AutoSteem. Just needs a more manual curation approach.
Of course, I can understand a Search feature will be difficult, but this is just filtering new posts coming in.
In GitHub it is "waiting for microservice" which basically means that they first need to implement something that allows them to filter and query for data, rather than just providing a stream of what the blockchain returns. It can be done, but my understanding is that there are some higher priorities to get done first.
I think the two main reasons for the microservice flag are scaling (Create a "search" service which can be scaled separatly instead of scaling the whole application) and avoiding implementations that have to be refactored later when implementing the microservices. Those reasons are pretty valid from my point of view so #NoOffence.
Beside that I do not see any other valid reasons why this has not been implemented yet, because I guess that the implementation itself should be quite easy. - Do you know some?
Actually I've already scanned the whole blockchain some weeks ago using my Java-API to collect usernames and their IDs - It was done in about 2 days consuming about 2GB of RAM so the resources should not be a problem at all. We also would only need to save the metrics (like number of votes, number of characters, ...) for each post and not the whole content of it - This saves a lot of disk space. Also projects like SteemDB have shown that it is not that hard to scan the blockchain and store the data.