I want to see topic-specific relays and client features supporting them, like a place to discuss politics, a place people can share porn if that is what they want, etc.... the point being that not everything needs to show up in someone's main "feed". If I follow Jeremy who likes to post porn, but also talks about rust, it'd be nice to just follow what he says about rust and not have to also see the porn.
How can we make that happen?
>assuming rust and porn users do not fill the same social grouping
I do share the latter sentiment. Having filter control would be nice.
Also, your desktop client is great!
Well, this specific example could be solved with a "exlicit" tag (clients/users woul need to set it though). But I suppose you are thinking of a more broad solution? Some days ago I read about relay sets: You define specific relays for a specific content and switch them easily in your client to change the view.
That's a good idea. I think whenever someone posts, maybe there should be a UI knob of some sort indicating where they want to direct that post: to my "wall"/"microblog", "to community X", etc. In this case "to communitiy X" would be a set of relays configured in your settings somewhere. Maybe "chat with my family" is one of them.
tags on notes and you follow not ust a user but a user plus some (sub)set of their tags?
That would keep everything in a person's 'outbox' to be topic-filtered at will be readers. I want to compare this to the idea of posting to relays that you do not advertise as posting to. I'm not sure when you would want to do one or the other. Something to chew on.
Would multiple identities work for this?
I had thought of that. Making a different identity to talk freely about politics and keeping Michael Dilger as a developer who tries not to talk about politics. But I couldn't keep my damn mouth shut on this account (!), and switching accounts would be a pain if not supported by the clients (it's on gossips todo list).
Multiple identities is inevitable because it’s not feasible to expect everyone to hang off a single keypair for eternity and people are comfortable separating and segmenting parts of their life. Not everyone will do this but enough that it will be an operating model.
I like nostrum and nostrconnect: That puts identity back in the hands of the user which to date have been too client oriented.
Having an okta type system where you login to the one identity and then connect to various services from there makes more sense to me.
If open source clients aren't in the hands of the user, then I don't know what is. I don't fathom how online services like nostrum or okta are putting identity "in the hands of the user." They seem to me to be taking it out of the hands of the user. "Trust me with your identity" sounds to me like "I'm from the government and I'm here to help." But surely I misunderstand.
Gossip reflects my own tastes which are highly self-sufficient with low-trust. I don't want to be tied into any particular provider, including identity provider. Anything that can be managed client-side will be. I will aim to give users maximal control, and it will always be open source so you can read what it is doing and compile it for yourself.
Nostr provides for both the identity and client in user hands but so far most people have experienced nostr through a client with their identity being secondary, often provided by the client (Damus for example you don’t have a contact list if you byo keys)
Nostrum (or others) would allow me to:
- have multiple keys, each keypair being it’s own identity
- authorise keys to certain apps
- manage contacts for that identity in a single location
- manage profile for that identity in a single location
So instead of choosing where I want to go (client) and selecting my outfit (identity) when I arrive, I choose my outfit and then decide where to go when dressed appropriately.
I’m not going to use my main keys, or my real name keys to go play poker; I’m going to have a poker identity. Those keys will be authorised for the gambling apps in my Nostrum and that profile can look entirely different to my others, different Lightning wallet, different badges etc. For all you know StackSatsIO doesn’t know how to play poker, we could play together all the time under different nyms and not know each others other keys.
Take this further, when real world services begin integrating nostr im going to need to have things like phone number and drivers license available (ie in an ubereats competitor) - I don’t want this identity and this lightning wallet attached to those parts of my identity though, I’ll run separate identity for that and only use that for those apps where I need to expose it.
Identity will decouple and become more central to nostr as more apps come online. Right now you can manage flipping between the clients with one identity but when there are 100 or 1000 with everything from social to porn to finance to who knows what?
Nostrum in this case becomes like a vault / sso that I use as a launchpad to navigate between apps; I control my vault so I control my identities and I decide which keys access which clients.
I’m not tied to nostrum here either; those are my keys and my identities, I can go to another vault provider and bring those with me so there’s no lock-in - they’re merely the nostr identity client I use to connect to nostr content clients.
Thanks for explaining that further. That all makes sense.
I was looking at your post from the perspective of "where are your keys"? And being a desktop-client developer I wasn't thinking of the model that your client may be out on the network somewhere (web hosted apps).
Your identity provider should certainly be the closest thing to you, and yes you take that identity out for a spin on the town. Nos2x is like your identity provider. Gossip as a local desktop client is a client and identity provider tied together. Nostrum served from a webserver could be an identity provider for people who are willing to trust dynamically served web content with their keys. nos2x/alby feeding nostrum being preferred IMHO.
I can't imagine having more than a small handful of identities. Firefox has Multi-Account Containers that work just like this. Websites see very different identies when browsed from those containers. I've only ever had about 6 or 7 such identities, and managed client-side has worked out for me.
However, if you want to use many different clients with those same identities, and you have a lot of extra functionality surrounding those identities, then combining the client with the identity provider kind of locks you in. I don't want to lock anybody in. So I'm open to having a pluggable indentity provider in gossip, but there has to be (among others) a local desktop provider that is open source that I can read and learn to trust.
Yep you get it 🤙
Perhaps someone starts a relay and then doesn't just accept anyone who pays, but vets the person before admitting them. Perhaps you check their profile, or they have to have a certain NIP-05 to show they are a "nosterpleb" or whatever, or they agree not to post porn or whatever to this relay and only post about certain topics, etc. Relay operators have that kind of control, right? And they could kick people out for violating the group's/relay's rules. Just thinking out loud, online...
Great interview on Nostrovia, btw!
I think we will get there.. imho we just need a few things 1) easy low cost relay deployments 2) easy ways for moderators to curate the relay content/userbase. Like discord servers sort of..
If nostr could do private group chats that could work too for sharing a relay but I don't see any nips for that..
sounds like relays might run the risk of the publisher problem.
If you are referring to illegality, I'll consider that off topic. I shouldn't have used porn as the example. I'm really just trying to focus on how to divide up topics in a way that I can follow a (person+topic) and not (person+alltopics), as well as create my own posts that are topic-specific that I know not everybody following me might want to see.
This sounds a lot like lists though (NIP-51)
I don't understand yet. What goes into the list?
Well from what i’ve read of the nip, it can be a list of pubkeys, hashtags, or events that a user follows
You could use kind 30001 (nip 51) "Note Event List" to inform your client that you want to follow all replies to specific events, or you want to *avoid* all replies to specific events. Then if all porn was in reply to a porn topic event, you could avoid that. Is that the idea? It is different from the other three, though I think using a topic tag would be more direct.
#[4] help lol
lists are meant to be flexible enough to hold anything, though rn only have lists for users, hashtags, and events defined, I also think lists of relays or lists of other's lists should be added.
lists are essentially tag lists and can be public and/or private. user tag lists can also hold the relay hint field so you can specify which relay to use for which user in a list.
my idea was users can create their own feeds by pulling in the lists they have saved. so you could create a feed by pulling in a list of hashtags queried against a list of relays. or a list of hashtags from a list of users (using the relay listed for each user).
what do you think #[1] ?
I think it is a great idea in general. I don't think it solves the particular issue of this thread (unless I still don't understand it) because a user has to create such a list first, and that list couldn't contain an event that doesn't exist yet, the one where the person I follow suddenly posts porn... my lists won't know anything about that.
The problem of this thread is how do I follow somebody's rust-related posts without also seeing all the bitcoin related posts I'm not interested in? Of course I can't do that, I have to trust content authors to do something. But which something? I want to divide up content into categories or domains, where the author is doing the dividing, either by changing identities, or putting tags on content, or placing content onto different relays, and we've been discussing those three options so far.
I was thinking that authors tagging posts is the lowest friction way to do what you (as a reader) need them to so you can read about rust but not BTC.
I agree. I also think I'll support multiple identities. Then authors have two different ways to do this, with different properties for each.
I would love if there was a sports feed
I think all we need is for some clients to support 1) browsing the feed from a single relay (some already do) and 2) posting an event to a specific relay. Then I can join the Cooking relay and send my notes about cooking only there.
I don’t think tightly coupling groups (public or private) to relays is a good idea in the long run, but in these early days I think it would be a great way to approximate Facebook-style groups.
I’ve heard #[2] mention this as well. Curious to hear his thoughts.
I think down the road there will be a lot of corporate relays with paid subscriptions for content. They'll be an extension of the paid streaming services now.
So I'm hearing three different kinds of answers (maybe 4 but I don't understand the 4th one yet):
1) Use different identities for different topics/communities.
2) Use different relay sets for different topics/communities.
3) Apply topic tags to posts and let followers choose what tags they want to see.
Were there others that I missed?
How will option 2 work when notes get spread all over relays? Can notes and replies exist solely on a specific relay? Would it need to be a relay that has specific write/read permissions? Would a user’s profile show their full history of notes or would some be missing?
The idea of community hub relays initally seemed reasonable to me. But the more I think it through, the more I like the other two options. Managing relays for that purpose seems like a pain/nightmare and makes it really hard to follow things. I think if you want to keep topics very separate, use a different identity, and if you only want them separate in an advisory way, use topic tags. That's where I'm at right now anyways.
Mix of personal, public, and paid relays where the clients have smart ways of finding the notes you need by connecting/disconnecting.
I agree and I like this best because it keeps all the smarts in the clients and keeps the relays more agnostic.
So I think being able to browse "relay global" is a nice feature, and being able to direct posts to specific relays is a nice hack, but even while offering those features I don't think they are how to handle different topics. I'll then design the UX to handle topics the other two ways, and leave those other things as manual override features.
Our current approach is your #3 option. Will there be some published taxonomy of topics? Do you plan to just use #tags?
I don't know, but I wouldn't want people limited by the friction of adding a dynamic new topic to an official taxonomy. I suppose #tags makes sense. There may be NIPs with ideas on this. I'd prefer to follow someone else's lead. I like the general concept but I'm not really interested in the details of how, I just want to do it.
It’s an interesting puzzle to solve and one I’ve been thinking through as well. How a user can engage in different contexts and possibly different “personas” with the least amount of friction?
Who knows how this will all evolve and what it will evoke from users in the future. I just have a feeling that configuring separate sets of relays for each different type of content that you want to post is going to feel cumbersome for most users. It feels cumbersome to me and I'm a geek. I think 1 might be the simplest / easiest solution but it limits you in ways that some people probably wouldn't like. I would certainly do that for some purposes, but I probably also want to be able to post as "me" about various topics without being someone else.
I think even my idea (3) is going to feel cumbersome to a lot of people who just want to type into a box and hit send. But I also think if the UI is simple enough and there is some peer pressure from followers it could fly.
But I also think this whole topic really depends a lot on the vision you have of nostr as a network going forward. My preferred vision has a big, interoperable fabric where organic "communities" might evolve based on follow lists (and probably follow of follow, etc. lists), but there are no hard and fast silos as could be implied with more purpose-driven relays as in 2 and your original post that made me think about usenet.
I think we need a “no broadcast” tag
For topic specific relay it would be something the relay says to a client, not on a per note basis by the note publisher (I would like that too tho)
a relay would have to white list clients that respect the “no broadcast” tag
because some client devs will want to maintain their rights not to support this.
the other option is to build clients that allow you to stop rebroadcasting on a relay level… then white list the clients that support this in some manor. the problem with this is one person who doesn’t check that box and now you got a bunch of tidal links being spammed from the topic specific relay that is just to host the song your currently listening too to all the other relays that person has listed. So it really should be something a relay says to the client.
