Mike is on the right track.
I believe the way to achieve his path while maintaining maximal optionality, adding needed topical granularity (and introducing compensation) is my response here:
I wouldn't subscribe to a community mute list unless the community was extremely small and I had a high degree of trust for those in it (risk being: some mute-happy dingus keeps me from seeing stuff I'd like to see in a way I can't get around in that community). But what I'm describing here is just a worse version of WoT.
WoT solves the problem much better, with some modifications:
- don't limit the web to 2nd order connections. Keep it going much, much further.
- "trust" in said web needs contextual tags. I might trust you highly for your opinions on Rust (and want to see your + your Rust connections notes in that context) but trust you less on "Mute" and may want to filter you and your "mute" connections out at will.
- use clients to filter your feed based on the trust contexts. "show me everyone; show me Rust + Bitcoin; show everyone but filter out Mute", etc)
Trust models that treat humans as a monolith are an anti-pattern. My human connections are each a complex of contexts and I almost never have a binary feeling about a person as a whole.
The web of connections is modeled as a flow network, where "trustiness" (along a context/tag) flows back to you from each network node according to how "open" the pipes are between you. ie "how much do I trust a, how much does a trust b, how much does b trust n, etc." where your first order connections matter most to you and the flow beyond them is determined by the subsequent hops. Someone you trust highly on Rust who trusts someone else highly on Rust - this last person you can trust a lot because of your connections in between.
And if you and that final connection have a very different trust relationship for a different context, you'll view them accordingly for that context (importantly: separately from how you trust them on Rust).
I have worked on a similar system in a different stack (urbit. The project was called "Area"), here is a brief overview of how that worked: https://gist.github.com/vcavallo/e008ed60968e9b5c08a9650c712f63bd
Discussion
And before anyone says it: the way to handle the problem of "but I'd have to select a million topics in the filter!" is tag composition:
I collect all my separate "programming language" tags together and create a new single "programming" tag. Now I can filter based only on that. And if it turns out that I've done a good job of curating that "list", others might simplify their life by simply assigning high trust to my single "programming" tag.
Or, just for fun, maybe someone really dislikes my curation and construes my tag from _their point of view_ as "woke programmers" and negative-trust-ranks it. This effectively mutes me and my graph for THEM (only about woke programming) while effecting me, my point of view and my graph not at all.
It is clear to me now that I need to write a long-form post about this.
coming up.