Thank you to those of you who made it to my demo of the Hive Mind browser extension. For reference the video can be found here. You can probably skip to the 8:00 mark or so to skip intros, etc:
Transcript: https://hivemindhq.io/2026-04-14-demo-transcript.txt
There were many topics discussed but I’d like to focus on a few that stood out to me:
1. [address] - trusted for - [some topic]
“trusted for” atom = 0xe55923557a4bc0ce15f91945eb2d4fca92e1a6fa8074378bcd8400eeb8b79176
This is the triple I expect to use for trust circles. If anyone has any objections then please let me know. A couple important points:
- “trusted for” is using a TextObject atom (simple text). I prefer the simplicity of text atoms when there is no reason to complicate with structured data (stringified JSON or IPFS-resolved data)
- Self-nomination to become a curator topic will be signaled by a user trusting themself for a topic
- There were some suggestions that topic atoms should be represented by structured data with embedded properties to signal that they are meant to be used as TOPICS. I’m open to this as long as the embedded data is minimal and doesn’t contain too much opinionated info.
2. X usernames and IDs
X usernames are mutable, which means we should use their immutable user IDs as the atom to represent them (like x:123456 maps to @smilingkylan and vice-versa). This username-to-user ID API endpoint (and vice versa) is not cheap and I doubt many dapps will want to pay for it. The tricky thing is that redistributing X API data goes against their terms of service so Hive Mind is NOT willing to perform this role and anyone who DOES can have their X developer account banned.
Let me know if you guys have any further thoughts on these topics or some of the other topics we discussed in the demo including the following:
- Staking conviction / price discovery for trust tokens — You explicitly called out that you’re not yet pushing users to vary their stake amounts, and that “price discovery” for trust tokens hasn’t happened. You asked the group: when should conviction-weighted staking matter, and how should the weight be used (trust weight x claim weight = ranking priority)?
- Disagreement signals — how do you feel users will be most likely to express negative sentiment when they don’t think someone is trustworthy? Stake on “against” for the “Alice - has tag - trustworthy”? Create a new claim “Alice - is not - trustworthy”? Or will users adapt to notice when a more “critical” claim for that account / atom type is missing? For example if 95% of crypto CEOs have the tag “Trustworthy” or “Builder” then any crypto CEO without a lot of stake on that claim will look untrustworthy.
- Applying the extension to other websites — I demo’d this functionality for X and we are able to do something similar for just about any other website (YouTube? IMDb?). I’m open to ideas about how best to do this (hire more devs in-house? open source the repo and let people contribute?
- Triples as search algorithms — mentioned at one point but I’m not sure I fully understood what was being said