Yes. I know a lot of people, including myself, that have done this.
Client software wont want to narrow their market to a particular social subset for moderation purposes.
I think the functional differences between apps will drive the users to their preferences. (One app being better at bitcoin stuff, one being super scriptable and customizable, etc)
After users have their preferences, then they will pick their preferred relays to shape the content. Some are filtered and some aren’t. Clients will allow users to toggle and organize as desired.
This is how it works now and how it will continue to work going forward. Relay curation and mod is why people love nostr.wine. Simultaneously, people clearly chose to add relays like damus and welcome.nostr.wine, they are valuable too.
As I was telling Vitor in another branch here, moderation clearly happens at BOTH the relay and client side and I don’t understand why he’s implying it’s mutually exclusive.
He can disagree with fiatjaf in spirit but I don’t see how “viewing the code” on a client clarifies anything this tricky 🤷🏻♂️ it’s all kinda philosophical and vague
Ya I think we both agree in spirit that we want the user to have control and clarity into what they are and aren’t seeing.
We don’t want “smoke and mirrors”, or a “greater influence” over the user content.
Of course, the context is evident.
I was mentally treating the terms “moderation” and “filtering” as synonymous, since it seems that’s how you view this (I’m trying to read between the lines).
You are talking about “proof in code” which doesn’t really line up with what I think of as “moderation”. Moderation is clearly a social exercise, not a technical one. Reddit mods are not engineers.
Your logic and posture still doesn’t add up to me. 🤷🏻♂️
In what reality are these two routes mutually exclusive? Under this delusional reasoning, shouldn’t your client be blocking users from consuming curated relays such as wine?
Obviously moderation happens at both ends of the network based on the user profile on the client side (their lists, etc) and the relay they’re exchanging info with on the other side.
This is ridiculous. The client is NOT a platform for moderation. Ever. Period.
Data should always be reliably, faithfully and transparently shown to the user. WITHOUT servers or assistive backends in ANY capacity. Direct client to relay only.
The user can make informed decisions about what they see and how they possibly moderate and manage their intake.
And the client should enable the user to control that for themselves. Regex patterns, block + mute, maybe even something like OpenAI prompt filters (if the user is willing to provide their own API token ofc)
“The code” doesn’t tell you shit about complex problems like this 🧊 nostr:note13t6nqmrq3axl7x4yh2z36fkdw2cht6rfq3pykazkmnrmmw8rrvjq44646z
And with this in mind…
I’m proud to announce the soft release of nostr-kit!
nostr-kit is cross platform, open source "heart” of topaz (which itself is open source).
It has been an intense effort to take the best (and learning lessons) of my early topaz builds, and formalizing/repackaging them into a mature library for industrial uses.
nostr-kit is designed for both clients and server (relay) applications that span across any platform or architecture that can run Swift.
It’s an extremely tight and efficient packaging of the cryptography, concurrency, and networking tools needed for any given nostr implementation.
Now, I approach the topaz project with this new library, in hopes that it can add the final layer of polish and performance I was looking to achieve before we open to users.
https://github.com/tannerdsilva/nostr-kit nostr:note1t3e2yh8qgrw6qr2z90skq9v8qd44n8sdw559vnxamg3nfpzdxrqse7p6zm
SwiftUI on the Linux desktop looks EXTREMELY promising. Native gnome with accessible and familiar syntax. It’s possible right now (not speculative), if you’re brave enough to be the first to deploy it (I certainly might be…before end of year).
topaz is swift only, but that absolutely does not mean it is Apple only. A thoroughly native Linux desktop client would be huge. It’s very very attainable from a technical perspective. 🤷🏻♂️🤔
Still waiting for Swift on Android to catch up….Windows is also hopelessly behind (shocking I know). nostr:note164w0uw30nhkgfutwvakz7xapef5sdwe02xzysy4rj0wnu2yxey9qut590e
I’ve been silent on topaz platform support. The repo exists…I know people view it…and I’m sure people recognize it’s an iOS app.
Have no fear, this app is NOT staying in the walled garden. This is simply the start. My bead & butter trade is in writing very high performance C & Swift code for Linux…I’m NEVER reaching for the “Apple Platform” libraries. I’m just here for the language as an open source initiative.
On top of iOS being an obvious entry point for a swift project, CakeWallet started as a Swift app so beginning here also gives a nice nod to the brand and the guy supporting my developments here (Vik)
I agree completely here. maintaining some kind of network on this protocol is something I am very passionate about. There is so much promise in the spec.
Working really hard to deliver something that isn’t complete shit (or even close to). This is the only way it could “catch on”, because shitty nostr apps are like 10x worse in UX compared to normal apps (due to the added network complexity - moving fast doesn’t help the UX either).
I think I have something very good in my back pocket, but nothing is certain.
At the end of the day, it’s not surprising that the strong culture of Lightning maxis that broke ground on nostr led us to a bad UX….
Apple slapping the shit out of these users is possibly the only chance anyone has at trying to move the culture and attitude of the userbase as a whole.
Let’s see what happens…don’t lose hope.
I’m banking on inline invoices still being supported. 🤙🏻
tbh I was trying to avoid bitcoin L2 at all costs and it seems like it might be possible now
No zaps for topaz!
Framework laptop preparing to ship 🔥
The world did not need another JSON parsing library.
But in the context of using nostr with Swift, there was a major gap to fill in the performance department.
QuickJSON is my answer for this.
Building a ton of tooling for nostr. First, I lay the foundation for my work…
Introducing QuickJSON, the fastest and easiest way to handle JSON in Swift.
It abstracts the excellent C lib yyson into two simple functions (encode and decode), without abstracting away performance.
Type-strict languages ftw
Just discovered clib yyjson. Impressed - will be deeply integrating this into my nostr lib.
NIP-42 is trivial to implement on an otherwise functional client
As nostr survives and grows, I think NIP-42 will become a requirement. At least, it will be for DM access.
Of course, DM’s came before AUTH, but now that both are solidified, it’s kinda crazy that the default configuration for relays is to share all DM metadata openly for all to see.