Was I wrong?
I always assumed that specialty clients should be able to easily outperform Amethyst on the quality of the features related to their specialty. Users would gradually move away from Amethyst as more and more specialty clients move forward. This culminates with a slow death of Amethyst, but towards a more exciting and decentralized future for Nostr. I have accepted this fate since the early days of the super app project.
This assumption was based on the fact that our development team would simply not have the resources to dedicate the same level of attention and support to every single specialty within Amethyst.
It has been one year and I am sad to report that I have been proven wrong over and over again.
For some reason, developing specialty clients is harder than developing the same features inside of Amethyst.
And that is a loss for decentralization.
Login to reply
Replies (119)
Sure, but one full year is enough data to take extrapolate.
So it might be worth to split Amethyst to smaller specialized clients?
Economines of scale and concentration. Not too surprising ...
Sure, but If everyone is failing, why would we do the same?
Amethyst is huge, overloaded and difficult to understand in some points, It's hard for me to use as an ordinary user. I'm really surprised how you managed to make everything work fast and solid, and yes, I'm talking about the Android version. Anyway, thank you for what you do. Maybe it really is worth releasing a light version of Amethyst with basic functionality which will be implemented in the most solid way and will become a beacon for everyone else.
Yeah, I think I severely underestimated the complexity of multiple clients on the users minds.
I don't know... I would love to, but reality has shown me that making splits work is very hard. π€·
There is only an android version #Amethyst?
I'm not sure what the problem is. Amethyst is go-to client and I love it. With a few minor exceptions, everything works, and once you understand how the various types of relays work, and the outbox model, it's pretty intuitive. I'd like to understand what the specific problems are. Because my experience has been great.
I only use amethyst on mobile, oh andolass
read this and be surprised. knowing zero about coding, I don't know anything about your efforts. what it need is a clear idea about users, what they want.
Nostr's essence is that we can use a social-like client, a special client for img or blogging etc.
Amethyst is the perfect app for light Nostring, fast to read and wonderful to scroll. complete of anything Nostr users need.
I shouldn't want Amethyst to compete with other clients.
#My2δΈ° and thank you for your hard work
Um Amethyst Lite com foco em desempenho. π€ π
Everybody asks for that but multiple devs have tried lighter versions and few people use them. π€·
The problem is that Amethyst is incredibly well done and you are a very talented programmer (which makes it even more sad that sometimes you use these talents for the evil), meanwhile very few people are really trying to do specialized clients and most people who try won't be able to do a very good job anyway.
Nostr is still too small and lacking the right kind of developers to accomplish all the tasks we have on the plate, such as developing a ton of specialized clients, so I think we will need a few more years to really know the truth about this. I am still betting on the specialized clients.
I don't want a bazillion apps on my phone, if I need it I keep it, if not its gone. So far Amethyst has done everything that I need so I don't use these other apps.
I wonder if its a nostr adoption issue too. So far, people have come to nostr for censorship resistant microblogging (and to talk endlessly about bitcoin). You don't have this mass of people demanding all these other use cases. They want microblogging which Amethyst handles quite well.
Me gusta usar Amethyst π
idk, I used only Android. Seem to be web also
Writing android apps is annoying as fuck. Hats off to you Vitor for mastering the platform, Amethyst is awesome. But not a lot of talented app devs willing to work for little to no pay. Eternal open source dilemma.
You might be overestimating how much can be done in a year. Most projects donβt get a whole yearβs worth of development done, because people work on them in their spare time and itβs disheartening to see the minuscule progress making everything even slower. Building something for free and supposedly for fun (or why would you?) makes it less likely to be polished and well made.
I am starting to think the whole "Nostr is simple and easy" is just a fallacy. It's easy to develop a shitty client. It's very hard to develop a good one that people actually want to use.
Nostr is supposed to be easy. Most clients are done in a couple months, max. Maybe that's the problem. Because nostr is easy, devs give up way too early.
But IMO, one year is a HUGE amount of dev time for any app, even outside of nostr.
That's exactly my experience.
Especially for mobile with restricted resources.
I assumed at this point we would have a lot more specialized apps like managing lists, deleting events etc.
But what I always see is more devs trying to build more kind 1 clients and them giving up because its hard and most people using kind 1 clients keep asking for super apps and them they dont use the features they asked for
This is definitely true, but it's still simple to do simple stuff like make a bot or embed a custom naΓ―ve feed in your HTML website, or make a relay browser client like
I don't know, stuff like that. But still it's nice that it's possible to make a shitty client very fast and grow from there.
I also think that making a Twitter-like client is the hardest task, while a NIP-29 client is much easier -- but still, making it really good, anything, will require a ton of work, even a stupid note-taking app is very hard to do well.

Jumble
A user-friendly Nostr client for exploring relay feeds
I agree with this completely.
I also feel that no one uses all these features, but who knows.
There seems to be an inconscious belief that always having more features will bring in more users and make Nostr a success.
Spring browser tried that approach. I am not sure if that is what people want. It could work on the desktop, but I think mobile is a different mindset.
This is true for software in general
Development is also just one piece of the pie
Maybe the culture being focused on simplicity and not quality makes devs think everything should be easy give up way too early. π€·
Agree as well. Maybe this is a side effect of projects having a list of nips they implement in the home page.
Viewers think that is a todo list everyone should do.
Also, often times I found myself debugging NDK and it took a lot of time because I did not write it.
You and other devs who wrote the libs and sdk-s have had the advantage of using your own stuff much more confidently and whenever there's a subtle bug you can just quickly fix.
This advantage is diminishing as nostr matures.
One other thing: Specialty clients get less attention because media is after Twitter vs Bluesky vs Nostr for now. This will also change rapidly soon.
Once there's more attention on other apps, there will be more feedback and so better apps.
Usually in software we think everything is hard. We fight our way through massive APIs all the time. Nostr is refreshing from that point of view. But everything else is still hard.
Yeah, libs can be helpful but they also get in the way all the time.
Trying to make yourself redundant is the easiest way to make yourself indispensible.
I don't know why. But I've proved it to myself many times.
Maybe it's how you act when you don't care about being needed?
Really need list management in Amethyst man.
We're probably launching #Alexandria v0.1.0 this month (so keeping to our Road Map yay!), and we started in July, working part-time. Although, it's a whole platform, with multiple sysadmins and a data analyst, and a new SDK, and stuff, and multiple new NUDs, and not just a list microclient, or something.
But still, building it is way harder than building the original Kind 01 clients because there are so many "Basic NIPs", now, and they're complex. You have to build all of them and then add your own twist on top. Have to really have a tight story board, unless you're a lone wolf, and lone wolf development has become onerous.
And there's no real market for microclients because it's much easier to add one more feature to a bigger app, than to create a new app containing that feature. The friction of moving end users from one app to another is too high. Making a market for plug-ins or extensions, is better, so we're concentrating on that.
We realized that, early on, after I did some market research, and decided we need to Go Big Or Go Home. We're sticking to enterprise-level development, where we have a strategic advantage because we're professionals and used to handling larger projects.

Are you looking for compliments for Amethyst?
Joking aside, I subscribe to the "problem" expressed by fiatjaf, Amethyst is done very well, and this perhaps holds back the development of other specialized apps of good quality. But with time there will be more variety and quality, it is still too early.
What became of your NIP-01 rework? That would be important. Not all the rest.
Similar reason as to why most of the world still uses MS-Word. Hard to break habits formed in the early 90s. Likely, #nostr as a social media use case will land on two or three clients: Amethyst, Primal and Damus, but #nostr due to an as yet identified use case will thrive. The internet didnβt really take off until the web, and the browser; it opened a whole new frontier of possibilities. I predict the same for #nostr
Keep in mind you guys have traction. Speciality clients need to build it. Building it with little to no users is harder (mentally and practically). The fact that the feature exist in the everything client is part of the problem to some extent.
The trivially obvious part is done quickly, but the less obvious stuff takes time to figure out or youβre just making yet another carbon copy. That doesnβt count as a specialty client in my view. I may be biased in my own way, spending too much time on large codebases.
There arenβt that many teams who could pull that off out there. Kudos
The move of Kind 01 to NIP-10?
That convo gave us generic comments, at least.
Daily drivers make a ton of sense.
Users want to engage with notifications, conversations, zaps and the most basic content types in **one place**. I do too.
It's for opening (and even more so creating!) niche content types that they'll need specialized apps.
Next to that, apps that bring all your [Enter Content Type] together in a manageable library will play a big role too. Music player, Podcast player, App Store, Workout Tracker... Although, these apps should probably link out to the user's daily driver for a great reply-, zap- or notification experience and instead :110percent: focus on on being a high quality place for finding, creating and (dis)playing the content type they focus on.
These two types of apps are complementary with daily drivers and make them even more valuable. Making them obsolete is the last they'll do.
Frankly, I have been looking for the set of apps that could crash and burn Amethyst into the ground. But I don't think that is going to happen anymore.
It went nowhere. I think @fiatjaf and others believe kind1 should take an important role on the spec. I completely disagree. We focus way too much on kind 1 build ups. De-emphacizing from the spec could be a good move.
NIP01 should focus on the web of trust aspects of kind 1, not on the small notes itself.
I wouldn't call NIP-22 "nowhere". That gave clients like ours a widely-used reply kind, which is important for making sure OtherStuff doesn't become too isolated.
Amethyst is like wordpress and the individual apps are plugins
Yeah, that's why we decided we needed something Really Different and Really Big, so that it can expand out in different directions from there, in some new market. Pointless to come up with something that's almost-Amethyst. Alexandria isn't actually our flagship product, but it's something we personally want to use and feel passionate about, and it was a nice Introduction to Nostr Development project, since it uses the NDK and Svelte and all this other #StuffNostrDevsLike .
True
Couldn't we just replace the reference to kind 01 in the NIP-01, with a reference to the (optional) kind 1111 in NIP-22, and then move kind 01 out? That seems like a compromise.
Maybe the issue with specialty clients is the lack of UX consistency. There is an expectation of "what works" on Amethyst. When users install another app, they need to calibrate themselves to a new expectation for just that app. And that is tiresome for users.
We need to figure out a way to normalize that across apps.
Recently I'm trying the opposite with noStrudel. The codebase is pretty messy at this point and in my attempts to clean it up I'm finding it easier to build small focused apps like blossomservers.com instead of adding more to noStrudel
For myself a lot of it comes down the boilerplate. And over the last few months I've seen that get a lot better
Maybe this is the same debate about AI... Is AI an app by itself or a feature? Many NIPs might not be apps but just features. We just don't know which one is which.
Thank you for not creating yet another kind1 client.
Yeah, that's why this is so surprising to me. It is a lot harder to code one app for all the NIPs because each NIP requires a slightly different architectural design, user mindset, etc. Amethyst is also messy at this point.
But yet, we haven't seen specialty apps doing better...
People's lives are still highly centralized and many are becoming more so, even with Bitcoin, with Nostr and even trying to escape forms of control... Especially if someone is poor and from a highly repressive country.
After all, in general, it is always much easier to destroy than to build. All it takes is for some crazy person to decide to take everything that is yours.
Therefore, even if people come to Nostr and use it, they will always establish some point of stability and will make fewer and fewer changes, because every change always requires more time and dedication.
Another point is that because it is an anti-crisis network, its main use ends up being to provide more repressed information, that is, Nostr ends up being driven by news of risks and disasters.
And even with this use, it is not always worth posting, because if the person posting is poor, without Bitcoin, without prominence and from a destroyed country, no one cares and 'freedom of expression' will be of no use. It will be like talking to yourself.
you are not wrong, however your gauging of other developer dedication and/or competency and/or distraction was inaccurate. you are a legend. not everyone is of vitor status.
Or maybe it's not about competency or distraction but about product design.
Amethyst is just a copy-cat after all. It's easy to get product-market fit when @jack already did most of the work.
Truth.
That said, I understand what you're talking about though. For example, you added community support on essentially day one, and since then, you haven't added additional features. I remember you saying that full blown apps would offer better support. I understood that. However, it just has not happened. The dedicated community apps have died and never came to completion or offered better support.
Communities could be huge on Nostr. Reddit keeps fucking their users over. But we don't have a viable alternative yet. π©
On the contrary, look at Pokey. This feature needed more love in Amethyst, and after some pushing π€£ @KoalaSat built a better service. Pokey is great! It can happen! We have proof! But it seems it's rare and again it's based on dedication.
Yeah, Amber, Citrine, Pokey, ZapStore.. those are all working on Android, but they are also kinda orthogonal to specialty clients. These 4 apps are designs to work with all clients as opposed to take the reins in some specific feature.
Olas was the latest try. We will see how far it can go.
My man @PABLOF7z sees a new shiny and gets distracted easily π€£π«π«π«, but he now has minions, I think?, to help complete projects. Plus, I really feel that he understands the need for Olas.
Yes, there is a cost to that.
I heard discussion about "unified branding" as a plus for onboarding, makes sense.
But at some point users will have to pay the switching price, I don't see how to normalize UI on a decentralized protocol
Niche apps can integrate libraries to power complex things, right?
Culture goes a long way. We need to move from easy and scrappy to thoughtful and quality.
Basically follow what the designers and product people in Nostr have been saying all along :)
What kind of apps were you expecting, examples?
I read culture as monoculture.
Maybe a middle ground? Where we'll see emerge a handul of UI patterns which will be followed by most apps
Chats, Reads (Long form-only client), Calendar, NIP-29 (Slack/Discord-like), Olas (Instagram-like), Reddit-like (user is de-emphasized on the layout), TikTok-like video feeds, YouTube-like Long form videos, nextdoor-like (location-specific), etc
Basically each part of Amethyst could be a separate app with it's own notifications etc
These all exist or have existed for some time, but they are not doing well.
By handful I mean just a few. I don't know what handful means probably π
not necessarily monoculture, but having a culture that prioritizes quality instead of speed can indeed make a dent on this issue.
Communities/chats we'll see great stuff very soon.
I'm slowly secretely working on one of the things you mentioned π
Needless to say Amethyst is truly great, so its a high bar
I still think onboarding people to Nostr is about onboarding them to a Nostr Store of apps. It would be great if I could just reference them to the ecosystem instead of a single app.
Its a valid question.
There is minimal to zero attention on the transition experience between apps. 

I'm not against the rework in theory, I just thought it looked bad to move things like that, but now I'm thinking it could be good to do it.
But I thought you were a guy who talked only about what exists and not what should exist, given that you should be talking about the fact that kind:1 does have an important place in Nostr.
In my article from before I just acknowledged that and said that instead of trying to fight against it we should embrace it and make kind:1 it the central discovery/public-square/stream of Nostr from where all other use cases can flow and take a life of their own.
So if you're publishing pictures with Olas, for example, you could publish some just for people who are following you specifically in the photo apps, but sometimes quote some wrapped in a kind:1 so others can know that you also have this alternative photo stream, it's like when people posted a link on Twitter to their blog post or article written somewhere else or podcast etc.
Sure if you are tied to only the most used NIP, then it makes sense to keep kind 1 there. But if you are also seeing a lot of other applications being fully developed that don't even think about a kind1 post, that is evidence that there is more to it and that the kind 1focus is just getting in the way.
I do think both are true: We are mostly focused on kind1s right now and also we have apps that kind 1 doesn't even make any sense.
Support us in updating NIP-15 and weβll make you right for marketplaces at least
View article β
It seems to me there is a natural place to cleave between feature-sets based on what kind of event a user is focused on.
These would be best as separate apps:
Kind-1 apps
long-form apps
chat apps
marketplace apps
chess apps
dm apps
git apps
...
I avoided DMs initially because I felt they should be in a separate app. And long-form was probably a mistake to (badly) render in gossip, and given that we now have NIP-89 I could render the long-form title and a link to your handler instead.
To add to this, I've been looking for a Reddit alternative since joining Nostr. I also like to think I've been diligent in my searching.
So far there is primarily OddBean as far as clients go, and there is the "communities" NIP which has implementations on Nostrudel.
More than anything I'd simply love for Amethyst to fully incorporate a better model for this.
@cloud fodder is going to try and integrate OddBean with relay.tools which would enable on-demand "community relays" or, "topical relays".
To me it seems my personal goals on Nostr are very much in my line of sight.
However, while the concepts are coming together, the infrastructure is very entangled and unpronounced.
The overall user experience does not seem to have the same support going for it.
I can track these ideas to the point where I am using my own self-hosted OddBean client, running on my own on-demand relays. I could even accept Sats to allow other users to host their own communities on my websites.
Then comes the challenge of mobile- OddBean and relay.tools have both been designed in simple mobile-first approaches, but there is yet to be a dedicated mobile app for either.
This is where my personal desires for Amethyst's future lie.
I like to imagine one user could have a "tiktok" experience, while a other has a "twitter" experience, while I have my "reddit" experience. I think we all have various demands for all structures of social media, and flexibility + integration are the future.
Small apps have never held the same appeal to me. Anyone can code a Nostr client the same way that anyone can pick up GameMaker or HTML. It's possible but not practical, or preferable.
Competing with mainstream means delivering on mainstream successes, and more.
Can't disagree with quality, but that's not the point...
Take iOS and Android, both high-ish quality platforms yet two distinct UX cultures, migrating between them takes effort to adjust.
In nostr multiple paradigms could emerge, I love what @Niel Liesmons is proposing (very likely be used by Zapstore) but other designers will do other type of high quality nostr design. Some may just adapt to OS guidelines
Who knows what will come out, I would guess 3 or 4 main design paradigms, as I mentioned mentally "grouping" apps with Niel's UX will be natural.
We can only expect potential agreement on this while nostr is this small
If there's a library for a reply section then yes I can do that in my niche app
@jb55's nostrscript browser would go between the horns of the dilemma
I'm becoming convinced that won't happen, not in the first minute in any case
Most people will come to nostr for some concrete reason, not because someone told them nostr is cool so they want to browse what to use.
Once they understand the nature of nostr, know what the nsec is and so on, they are ready to explore what else is interesting - there is where the store appears
or write a new sdk, like i did, because go-nostr is a dumpster fire
i was holding my tongue until I have more working demos :P
two yearsβ’οΈ
I am approaching the problem from a very different perspective; instead of building a superapp Iβm betting on making the protocol incredibly interoperable; the superapp route was always going to be possible but I think it ultimately undermines the whole point of nostr.
What I want is a flourishing ecosystem of apps that tightly integrate with each other without ever having to know of each other; thereβs a reason I wrote NIP-31 (display unhandled events), NIP-89 (handle unknown events), NIP-90 (DVMs), NIP-60 (interoperable wallets)
I didnβt continue the work on Honeypot at the expense of Olas; I am finishing that work BECAUSE Olas, and Highlighter REQUIRE it.
Maybe Iβm completely wrong but I think an extremely composable ecosystem is the only way that this can possibly ever work in the long run; much like outbox (or something like it) is required for nostr to work in the long run.
Nostr may be hard, but what other option is there? ActivityPub is harder and Bluesky is nearly impossible.
This is the key.
Proof of concept. Easy.
Quality execution. Deceptively hard.
Also, I think itβs fair to say that most people donβt have a lot of appetite to try/use lots of different apps. Theyβre mostly happy with one thing that does a passable job at everything they want. Youβve more than nailed that bar with Amethyst.
The hardest part to replicate across multiple apps is the UI for onboarding.
Part of why this is hard is because we haven't even solved the UX problem.
I fully agree. Having one application complement and help build the overall puzzle can be very powerful once all of the tools are available.
There's only 1 way to do things in the NIPs. But the clients are a free-for-all.
How do you log into Nostr?
If you have to say "it depends", there's a problem.
Yo @StevenB easy to develop a shitty client. π
Yes.
πͺ
There is no #Amethyst Web. Are you sure you don't mean Primal? It has android, Ios and Web versions...
Sounds exactly like PHP and Javascript to me π€
I agree with this take. I think we scare people talking about nostr because they get overwhelmed by all the info (not everyone is a freaky who likes rabbit holes).. but itβs easier to bring them by one βappβ that fits their need. Once they get into the ecosystem we can introduce more and more clients/ use cases.
true
Sir, there is an entire www worth of 'apps' to copy, and who knows that new stuff the Nostr paradigm enables. My sense is the holdup is in devs getting the paradigm more than anything else.
It takes time, examples, metaphores, and probably a 1000 repeated explenations for it to become a general intuition most people will just have instead of some novel thing they have to aquire.
What? were you planning on rendering chess matches, weather rapports, agendas, video libraries, music playlists, maps and navigation, tournament brackets, recipes, blueprints, books, climbing routes etc.etc.etc. as well in your superapp?
Give it time, it will click for more devs, and with a growing userbase attempts at things are more likely to get traction as well such that they get sustained developer love over time.
Fucking love it
Well, if kind 1 doesn't make sense for some apps I don't see that as a problem at all and I am not trying to force those apps to use kind 1.
But many other use cases can have their own independent existence but also use kind 1 for signaling/discovery -- most notably the common "social" things like long-form events, video events, song events, podcast events, picture events, livestreaming events, calendar events, perhaps even nip29 group events.
Nip 01 is mandatory. Which means kind 1s are mandatory. If you think it is optional, the text is wrong.
All other use cases were using kind1 for replies but now they are all moving to use nip22. Kind 1 is really only for Twitter-like clients. 90% of nostr doesn't need to bother by kind1.
I agree that kind 1 must not be considered mandatory.
Then, let's remove it from NIP-01.
Totally feel ya! But what do you think would happen if we made it optional? π€ #JustWondering
I really hope @Vitor Pamplona's PR will be merged.

GitHub
Moves Kind:1 definition to NIP-10 by vitorpamplona Β· Pull Request #1076 Β· nostr-protocol/nips
This addresses a dev confusion that kind:1s are mandatory: Since kind:1s are currently defined in NIP-01 and NIP-01 is mandatory, people assume a C...
So you would have a reference to other NIPs in NIP-01? Like for implementation of kind 1?
This makes sense. A base protocol without a specific application. One had to look up another NIP to get something real working. So NIP-01 would lose one aspect of its beauty: itβs self-contained and complete. At least for the βSMS-caseβ in a world with βinternetβ.
Totally agree! Interoperability is such a important thing. You've seen my Nostr for Business deck and one huge inspiration to start working on it was the fact that all SAAS business apps like Slack, Notion,... are trying to be this huge superapp. The problem is that the experience is getting worse as they are adding more and more features.
Having small dedicated apps that are exceling in the small niche and are seamlessly interoperable with other apps is the way to go.
OK, time to get that thing moving again.
Trying to build 2 nostr clients on different tech stacks simultaneously has meant I haven't been able to make the progress I would have liked quickly enough. Maybe maintaining a third would slow down progress too much.
Was I wrong?
I always assumed that specialty clients should be able to easily outperform Amethyst on the quality of the features related to their specialty. Users would gradually move away from Amethyst as more and more specialty clients move forward. This culminates with a slow death of Amethyst, but towards a more exciting and decentralized future for Nostr. I have accepted this fate since the early days of the super app project.
This assumption was based on the fact that our development team would simply not have the resources to dedicate the same level of attention and support to every single specialty within Amethyst.
It has been one year and I am sad to report that I have been proven wrong over and over again.
For some reason, developing specialty clients is harder than developing the same features inside of Amethyst.
And that is a loss for decentralization.
View quoted note →
To me the onboarding MUST be done by a Nostr-only App Store.
I don't want to onboard to an app. I want to onboard to an ecosystem of apps and allow the user to choose.
User creation can be done by the store.
Imagine if @Zapstore had an onboarding screen that automatically installed Amber and logged into that for the user. Now you have a signer for all the other apps you may want to install.
The goal is to onboard to Nostr, not to any specific brand inside of Nostr.
Sounds like a super app.
It's just an app installer with onboarding.
AKA a "login with Google" feature. Just add Amber login to all clients. Amber already has a Create Nostr Account feature.
Each brand will solve this UX in their own way, though we'll see some patterns emerge
It's not a problem, it's to be expected if this is a decentralized network
This is the future I want
10,000x micro apps