Replies (47)

Contact lists and follow lists should be different concepts. Contacts being accounts you recognize and follow lists being contacts you want to ... er... follow. I'd like to verify for myself the real Joe Biden Account, but don't particularly care what his handlers have to say.
bootlace's avatar
bootlace 1 year ago
I would like to separate those that I follow on amethyst into separate groups, one way or another
Specifically, the idea of nested lists really appeals. One list with sub-branches following the same implementation. Likely simpler to code, interoperable, and easier to use across the whole of nostr.
This is why clients all need to implement lists so you can select which of your people lists you want to look at. The kind:3 "contact" list is such a blunt instrument.
They aren't the same because they're different platforms. Nostr fixes this issue. Lists fix this too. I could have a List of musicians I want to follow on Stemstr or bloggers that I want to follow on Hightlighter. We need more clients to use Lists.
listr is a client for making lists
JeffG 's avatar JeffG
This is why clients all need to implement lists so you can select which of your people lists you want to look at. The kind:3 "contact" list is such a blunt instrument.
View quoted note →
Nostr has lists… but it’s poorly implemented.
JeffG 's avatar JeffG
This is why clients all need to implement lists so you can select which of your people lists you want to look at. The kind:3 "contact" list is such a blunt instrument.
View quoted note →
I am aware. I'm just concerned that Vitor will implement some wild thing (again) that doesn't make any sense in the larger nostr-verse. (Like he did with his edit "feature" in amethyst. 🙄)
Yes. I get that. But implementing features that break compatibility with anything and everything else is not a good way to promote development of non-social media type uses, which I would like to see work as a cohesive whole. IMO. 🤷‍♂️
The first thing that pops into my head is using a list to push notes of liked/zapped tracks listened to on wavlake. Posting stuff you listen to seems to be a popular thing to do, so why not set up a list to automate that? Eventually, I'd like to have nostr keys integrated into a fork of nextcloud so that you can have a list control what nyms are allowed to access files without needing to have anyone sign in or deal with password nonsense. Heck, if there's ever a hardware nostr signer, you could use that as a controlled access door lock.
Does wavlake support lists? People could just follow you by putting you into one for their lists. Then they don't need to see your posts, just see what you are listening to. Either way, the list should be theirs, not yours. You can already use the current lists we have to manage access controls. That is easy. You just need to code the control itself (check if the key is in the list before downloading). I think Blossom has a version of that already.
No clue if it does or not. I'm just pointing out a theoretical user case for a list. That's cool. Do the lists integrate with each other? No clue if you're familiar with anything like PLC ladder logic, but, I'm picturing something like that, but, more versatile and only limited by a user's imagination.
For now they are only lists of public keys. There aren't any other meanings associated with them. You could do a PLC-like thing by reusing those lists or by creating your own style of lists.
How bout a way to save or backup (and to restore) follows & followers? kinda getting tired of all my follows & followers suddenly disappearing.
@Vitor Pamplona I would love to see a separate section on the profile page for "boost", so that in the "notes" section we could see more clearly what that profile. I think in this way it's easier and faster to have a clue of kind of content a user shares or create, or if it is more like a boost account.
Gm Vitor. I have been considering this for a very long time, of course how it relates to Nostr I have only been considering for the two years that I have been a part of the ecosystem. I see two problems that are very noticeable on Nostr. The first being a lack of "organized friend lists" and the second being a lack of "managed communities". Both of these properties are enhanced with a centralized database of course, while Nostr is enhanced with the emergent properties that are derived from the "all seeing relays" model encouraged by Blastr. I actually like the Blastr model if it is applied in a way that creates value and incentive structures. It's just that no one wants to host everyone's bloat notes (for free) if the cost is compounding upwards. Relays lose incentive. Instead of proliferating, they become constrained. So what I suggest is a forking of Nostr. Our npubs can be shared across different forms of Nostr which can become frameworks for different network relationship models. In this way we can manage "Other Stuff" without being a slave to the kind 1 note and NIP-02 Follow List format. I think a fully "decentralized" Nostr would be a fully distributed Nostr. That means every user would have incentive to host their own relay. This makes sense if we can reduce the footprint of "Nostr A" to something microscopic. If Nostr's identity layer can proliferate to become a standard that is built into every home router, then we can maximize the proliferation of npubs. @Daniel Wigton suggests hosting data in clusters of friend groups. He wants friends to share encrypted data between themselves directly as a form of redundant personal security. I like this model and think it could also serve as a model for relays. Relays need to organize. In this way, we can maintain different frameworks for standardizations of data interoperability without being committed to any single organizational structure. The thought here is that I should be hosting my own personal relay to host my own notes. If I cannot, then I should be able to find a public relay which would likely make sense to be a decaying type of relay. Do we have relays that decay yet? I would love to publish to a relay that guarantees my note will decay in 1 year, for example. Then I have the authority as a user to determine how long I want to host a note, or how long someone else should host it. It can proliferate and be guided by social peers, but in the end I shouldn't be writing permanently to anywhere unless I want it to be there forever. Which is not everything I say, necessarily. And most of my "thoughts and celebrations and memes" don't really need to proliferate across the internet, so much as they need a home to exist upon until I decide to delete them. It makes sense to have small personal relays and it makes sense to have totally open relays. What doesn't make sense is confining ourselves to "one Nostr". Even if it is open, it is still constrained by its organization. The employment of Nostr is dependent on its structure. So, "relay organization" is not set in stone either. But at first we should have a simple Peer-to-Peer relay authority structure. A relay would either be open to everyone, or it would federate with a group of other relays. Because these federated relays would all be sharing the same goal, they would not be less decentralized than Nostr is now. Instead they would provide authority structure within this decentralized ecosystem. This would allow parent/child relay relationships. The point is that relays would communicate but they would only do so by grouping and agreeing to read/write to each other. By Blasting events to each other. You have "relay networks" which are totally decentralized and stand alone You have "hybrid applications" which employ caching to aggregate data from relays And you have "social networks" which are unique in structure and dependent on user input What we don't have is trustless relay organization. And then we need a new Nostr for Blastr-enabled Nostr and this one can become testnet Nostr. Or inbox/outbox/gossip Nostr. Why aren't there already like 5 versions of Nostr? All models are valid, it's a question of application and incentive and structure. I am not sure how well I can format these concepts but I hope this comment is helpful in some way. I believe Nostr is attempting to do something that money cannot solve. Developers must break through to innovative ideas instead of relying on traditional fundamentals. We are in emergent territory. Light speed connectivity. There are new rules to be written. With that, I also want to suggest Graphstr, which would be "the beginning of Web of Trust or as I've taken to calling it, Web of Confidence". Graphstr would be a relay backend powered by Blazegraph with a Rust wrapper to communicate Nostr events across a decentralized protocol of Blazegraph relays. This would enable concept graphs to proliferate across a Nostr-enabled ecosystem, which could serve as a model for a future decentralized Web of Trust. Heck if I know. @Nice and Kind Vic I want Listr to become a protocol and not just a Nostr application.
i switched to nostrudel about 6 weeks ago because it was the only one with proper outbox NIP-65 support which helped a lot with my relay dev testing and now it's gonna have NIP-42 real soon (hzrd149 says he's got it as a high priority) which is gonna make it the number one client for my needs
Disagree. The appeal of Nostr is portability. It's convenient to carryover your follow list. Each app can allow for custom mutes. Maybe?