Back when I was working at corpo-world, my job description included something along the lines of Finding ways to constantly innovate, challenge the current work flow and always be on the lookout for new strategies that increase profit and cost reductions.
I can't really remember, this was 6 years ago, but it was something along those lines. I adopted that mindset for each and every aspect of my life, which could be considered a mistake because now I can't look at things without thinking how can I improve them, or what could be done to maximize production, efficiency, revenue, or cost reduction, even if it is my grandma's cooking. I just can't help it, every time I see a process, a service, or a product, I go on corpo mode and think of ways to improve them.
Now, as most of you may already know, Leo Finance just came out with a new way to interact and engage on-chain called Threads.
Threads are for everyone and are meant for anyone to write about any topic. This takes microblogging on a blockchain to a whole different level.
Some background on how #threads work
I am going to extremely simplify the explanation of the process, but it goes something like this:
Right now, https://leofinance.io/threads shows every thread created on the Leo frontend. Anyone can just click the yellow thread button and compose a short-form text post and publish it for everyone to read it.
What happens on the backend is that @leothreads publishes a top-level post that will be used as a container for every thread posted during a span of time, and any thread posted on /threads gets stored as a comment on the current top-level post from @leothreads (the container). Then leofinance.io pulls the comments from this top-level post and shows them as a top-level thread.
This means that threads are shown on the interface as if they were top-level posts but in reality they are just comments. This process avoids triggering automatic votes on threads as well as enables any user to post short form content without tainting their long form content blog with short posts.
Hive users can publish a top-level post on their blog, and then use the threads feature to promote that post, or to engage with other people's posts, in fact, many users try to reach new audiences by sharing their content on /threads:
If you look carefully, there's nothing wrong with how this hive user is maximizing the pros of /threads by promoting hey Hive content here while using a short description of the post and encouraging readers to click the link, she even uses some tags correctly!
This is beneficial for /Threads and Leo Finance, it increases the Ad revenue from all the clicks and browses but, there's one thing in this equation that is not fully working on behalf of Leo Finance: Clicking on the link shared here takes the user away from leofinance.io and into another frontend.
As you may have imagined already, one of the main points of having such a kickass feature like /threads is to generate more traffic and engagement on leofinance.io, and promoting a post that was not created through Leo Finance (or using the tag 'leofinance') takes any user who clicks on the post to a website other than leofinance.io, and any user who wants to comment or like this post has to leave leofinance.io to do so.
There's nothing wrong with this, in fact Facebook and Twitter user this same system that allows users to promote non-facebook content.
But what if this was not the case?
The Ultimate update for Threads?
I use a question mark because I'm not even sure the feature I am about to propose is doable on a backend level, and I have no idea how stressful it would be for the frontend, hell I'm not even sure the devs can pull it off because it seems like an extremely complicated feature even at the level I'm thinking it.
What if Leo Finance established several containers instead of just the one container (top level post that stores the threads as comments)?
 |  |
|---|
The pictures above show the thread containers as top level posts. As you can see they are pre-determined posts that store as comments all the content published as threads that will be shown in thread form in leofinance.io/threads.
Imagine that instead of composing a thread and storing it on LeoThread 15.9, you could use a tag to send that thread to a specific container, and the thread still shows on leofinance.io/threads as a top-level thread?
This doesn't sound like much, what's the use case here?
Let's use an example: @jongolson's CTP community publishes a contest as a top-level post where they encourage their members to make a post about the current state of newsletters in the cryptospace, and one of the contest requirements is to share the link to their post in the comment section of the contest while also engaging with other comments there, but they also want to encourage users to create a thread with their post and make some noise about the contest.
All @jongolson would need to do is set the CTP announcement as a Thread Container (using a process I have no idea how to make it happen), and ask anyone who wants to join in the contest to make a thread using the tag #CTPnewscontest.
By using that tag, the thread will get stores in the CTP announcement container instead of the default LeoThreads 15.9, allowing the users to interact with one specific post using threads, effectively making it possible for anyone to comment on any Hive post from threads, instead of having to open the Hive post and leaving leofinance.io to interact with the post.
This feature would allow anyone to make a container post and get a lot more interaction on the post by allowing threads to be stored as comments on this top level post. This will also give more visibility to the comment section of any announcement or post that wants a lot of engagement because everyone will be able to read that comment by browsing /threads, whereas if they just stick to commenting directly on the top-level post, only people who open said post will see the comment.
As you can see already, being able to post a thread directly into any top-level post would boost the engagement for every comment section of every thread container post, as well as increase the interaction on every comment made.
If a user doesn't use the specific tags that populate a specific container, then the thread created gets stored on LeoThread 8.7, but if they use a specific tag, it gets stored on another post (in this example, the CTP announcement).
Let me get deeper into this
Users can make a top level post and then ask users to reply on /threads using #MyTopic, and anyone using that #tag will be replying to that post, but also making a thread. This can increase engagement at a whole different level, and users will flock to /threads and create their own conversation about the topic, while at the same time replying to the top level post and generating engagement there.
Imagine hundreds of posts with hundreds of comments on the Trending Page of Leo (or any frontend for that matter) thanks to threads being able to reply to specific posts by only using a simple #tag
I'm excited in case you can't tell.
Everyone would be able to set their posts as a /thread container, and everyone would be able to generate thread ideas FROM hive, even if they are not posting from leofinance.io but from the Chess community for example, but the replies to the hive post will use leofinance.io to reply to that post about ANY topic.
This is an amazing feature (yeah, I'm patting myself on the back), especially if we go with the option of end-of-day rewards for threads, where users will know their chance to earn more rewards from a reply they would already be making to a Singing community post, all they need to do is reply from threads and their rewards will be boosted, because it is easier to vote a thread than to vote a comment (their reply to the parent post will also have tons more engagement and impacts because it will show on the /threads feed and not only as a reply on the parent post that may not have a lot of eyes on it).
The best part is that you're not stressing any internal DB because it's all on the hive blockchain, all the /threads interface needs to do is pull more hive blockchain posts and set them as parent containers and allocate comments to them by reading the tags a thread uses.
Users may have a decision to make: A post or a thread for an idea?
Make a post, have the conversation about it on threads.
Instead of users just sharing their post link on threads making it a plain promotion tool, /threads becomes a dynamic and fun way to interact with a post while also generating rewards from the end-of-day reward pool.
OR, OR, (Maybe AND) to make it even easier (for the users, for the code I imagine it will be hard as fuck):
A user makes a hive post, if they share it on threads, the code allows that all the replies to that thread use the hive link as a container, making the replies on the thread to also populate the hive post directly, without going to the peakd.com or ecency.com interfaces post to reply (let's face it, if a user makes a post about food, they will share a peakd post link on threads).
But how are users going to reply to a post they haven't even read
Well, here's another test for the Leo developers:
How about pre-clicking a link that leads to another place in the Hive Blockchain?
What if users can click "preview post" directly from the thread sharing a hive link, and they get shown the top-level post directly on Leo Finance as a preview, so that they can read it all, and then be able to reply in a meaningful way directly from the thread and as a thread reply?
This already happens on the normal feed Leo interface, a user can click a link and they will get a view of the post that can be interacted with, without leaving the original interface:
The Leo feed is still in the background of the screen even if I clicked on the link, so why not translate this to /threads so that clicking a link shows me a preview of a Hive post (no matter where it is, even if it's not on Leo) and I can read it, then click out of the post, return to the thread, reply to thread (using the tag) and boom, the user replied to a top-level post outside of Leo, FROM Leo and from threads.
More advantages for dynamic containers for Threads
Having the ability to use /Threads to reply to any post that is a container for threads, also enables the Leo Team (and any team on Hive for that matter) to generate collaborations with other communities to encourage their contests to use /threads as their engagement vessel, promoting threads as the way to reply to announcement posts and participation posts, boosting the comment section and the rewards for their users, because their comment will not only be seen on the comment section of the announcement, but it will also be seen from the Threads feed.
Imagine that with Threads, Leo becomes be the place for ALL the engagement and interaction for every single post on chain. Why would anyone give up to Leo token rewards if all they need to do is use threads to reply to a post, any single post out there?
My only question is: