There is a generalized over reliance on plain text application specific data published by Nostr clients, which is really concerning. Loads of apps publish this data every time you read notifications, set settings, check your home feed, or manage a premium subscription, among other things. All of this is normally published in plain text to your relays. This data is quite revealing, and the current default behavior of some signers is to sign these events by default, so they get published without the user noticing it. I don't know if you realize this, but it's pretty leaky. I would say it's even worse than centralized platforms collecting data because all of this information is public and in plain text. It's a privacy concern that exposes usage habits and other metadata to everyone, and all of this data can be used by anyone. Are you interested in the last time someone checked Nostr, or profiling an user? Just query for their latest events with kind 30078. This has to improve. Developers should be conscious of how this harms user privacy, and users should recognize how exposed they are. The first thing you can do if you care is go to your signer and disable signing these events automatically. The apps you use might feel a bit broken, and you'll have to sign these events manually, but at least you wouldn't be publishing these leaky events automatically. Now, I'm going to share a little list of what you can find out there... for free
- YakihonneAppSettings
- store-settings
- seen_notifications_at
- ride_request
- routstr-chat-api-keys-v1
- plebs/watch-history
- plebs-settings
- Primal-Android-App
- Primal-Web App
- Primal-Web App | get_app_settings
- Primal-Web App | get_membership_status
- nym-settings
- nym-shop-active
- lumi-settings
- ghostr-publish-history
- ghostr-processed-submissions
- fanfares/purchases
- AmethystSettings
And this is just some of them. If you want to inspect this yourself, you can use and modify this `nak` command:
```sh
nak req -k 30078 wss://relay.nostr.net wss://relay.damus.io wss://relay.primal.net wss://nos.lol | jq -r '.tags[] | select(.[0] == "d") | .[1]' | sort -u
```
- How do you code these days?
This is a common question these days. I've been evolving my way of coding since LLMs came into play, before the term vibe code was issued. I've been exploring the different paradigms and shiny new approaches that appear almost every week, but to be honest, it is not really for me how the industry and devs are leaning into these new tools and framing. Fully autonomous development is not for me. I use the tools, I test the tools, but I don't fully embrace the whole vibe coding propaganda campaign that big AI labs are shilling. I use LLMs to assist in my work, not to fully delegate it to them. By doing that, I can maintain a consistent mental model of the software I'm writing. I can make critical decisions on the architecture, security considerations, and everything related to crafting sustainable software. By using LLMs to assist during my work, I can delegate tedious tasks, assert spec compliance, iterate and polish parts of the code without introducing breaking changes, and make maintainability easier, while effectively being more efficient and performant in my work. I avoid embracing the fully autonomous paradigm because we are not there yet, and tbh I think we will never be. By observing the current trends in companies, we can see that a handful of them are firing people, not just devs or engineers, but also salespersons, technical assistance, etc. The result now days is very low to zero benefits and a perceptible degradation of their services, together with an horrifying generalized burst of CVEs, attacks, and instability. Humans with knowledge and expertise are very competent and they cannot be replaced without sacrificing quality, scrutiny, critical attitude, and the capacity to make aligned and informed decisions.
Why am I writing this? I think we are at a tipping point, and since last year things have started to change drastically. I think it is really important to talk and reflect on these things. I conceive LLMs and these new tools as enhancements, but not as fully autonomous entities with the capacity to take critical decisions in long term scenarios. They are like the Iron Man suit or a Mecha suit, an exoskeleton. They provide you with new skills and empower you with new tools and capabilities, but good luck with letting your agent run free for hours, days, weeks... as the industry is claiming, this is just my Pov, but I think it can also be a bit misleading for new people who haven't ever coded before, as they are finding loads of frustration when maintaining or just after coming out of the first MVP. Don't get me wrong, I love to see people who haven't touched any line of code before developing apps that serve them and their community, discovering the power and freedom that comes with creating your own software. But I think the approach should be to keep using LLMs to assist you, to learn and accompany you, and to dialogue, instead of fully detached development. This is a great opportunity to learn new things. It has never been so easy to get answers to your coding questions and learn. If you reject seeing a line of code, you'll end up with a mess, and if you don't know how to deal with that mess, you'll get really frustrated. And yes, it's true that LLMs are going to get better and more capable, but so is the mess they create, as they are delegated to perform bigger and more critical tasks due to the assumed competency. The bigger the mess, and again, of course, these things can be mitigated with guardrails, evaluation loops, etc., but there are no real solutions, and there never will be perfect solutions.
So just final words: Use the tools and don't let the tools use you. Take advantage of them; it has never been so easy to learn new things. There is no such thing as a free lunch, but all of this doesn't mean that you cannot embrace the fully vibe coding experience, especially with something like Shakespeare.dyi that already paves the way and reduces the 'free wheel' risk or 'hallucination' tendencies. But once you have a shiny new thing, good luck maintaining it