Too many Nostr #devs are skipping over the essential step of identifying actors and use cases / user stories, and discussing the specific models, objects, and environment of the application domain.
And it shows. You are programming past the users.
Discussion
muahaha
that they got to play architect without skipping aesthetics and phenomenology courses
What problem are you trying to solve?
Who has this problem?
Who feels so set back by this problem, that they would pay for a solution?
Who and what do they interact with, and how?
What are the typical routes and workflows they would use to enter, exit, and move through your application?
Why would they want to solve their problem with your application, rather than another (and don't mention Nostr in the answer!)?
If they are using another application, what might motivate them to switch (and don't mention Nostr in the answer!)?
Define the specific domain this application covers. Is it a global domain or some virtual space?
If it is a specific space, should you design it to occupy or surround an actual space, or should it still be completely distributed?
If it's a global domain, how private do the comms have to be?
If it's a space, how do you control access to the space? Does some part of the space need to have another layer of access or private comms? Is it okay for lurkers to see and/or hear all or some of the activity in the space? How do you find the space and gain/lose access to the space?
If it's global, how do the actors reliably find and recognize each other? How do they ensure mutual access to important data?
If it's a space, walk around that space. Decorate it, in your head or a drawing. Pick the objects up, examine them, put them down in a different place. Pick a notepad up and write on it. Put the notepad back down. Talk to the other people walking around. What are those people looking for? Can they still find the object you moved? Do they know you wrote something on the notepad?
Etc.
And we need to get away from the axiom that Nostr adds value. Maybe it does, in the mid-term, but using it comes at the high, immediate cost of losing or reducing the value you are receiving elsewhere.
Instead, figure out a way that using Nostr in your app tech stack allows for novel features, so that _those features_ are adding the value.
the value is not in the stack but its openness, simplicity and infinite flexibility
i'm procrastinating dealing with it but i can assure you bluesky has zero flexibility, all the openings nostr gives you do not exist in their protocol, even though it's "extensible" they have made the branches of its structure extremely rigid and closed - almost none of the nodes are able to sprout a new limb
Yes, but that is what adds significant value to Nostr _for you_ as a dev. It is not what adds significant value _for the user_ . And value has to be significant, to overcome the cost of adoption or switching, for the majority of potential users. You have to fight user inertia.
What it can do is open up your ability to design novel features or workflows that wouldn't be efficient under a different protocol. Things you can demonstrate concretely and get a "wow" effect out of them.
My point is that they shouldn't have to understand or care about Nostr itself, to be wowed.
which is why working instant messaging should be a top priority
In our domain, it's actually threading of conversations that has to be 🎯, because of the financial cost of missing an important part of the discussion.
That makes notifications UX even more important to nail.
that's client side
i'd argue that should be a standalone app, living in your system tray, running in the background
Your notification app = Your daily driver
making a notification app would be pretty simple to do
most of the twitter clones have avoided it because most users have too many follows and it would be absurdly noisy
unfortunately i'm busy, but i can see how it would be done
hell, i'd get a notification every minute or two and i only have 100 follows
I would really like to see at least a red dot for notifications in nostrudel I don’t want push notifications but they would be nice to.
well they could be a separate app, that's the thing
and teh app could have rulesets you can define, like users or tags, and you could set focus times as well
Seems good to me
Communities fixes this.
I.e. you choose per community what you want to be notified about and can actuallv target your attention and energy.
This is my dream:
Although not all notifications are from communities. I use, for example, ngit and gitworkshop. I would like to be interrupted a by "new issue on your repo" notifications.
communities themselves are a criteria, message types can be a criteria (easier if you make a tag to mark them, this is the mechanics of filters)
and sometimes you need to turn them off, either permanently or temporarily, permanently tends to a be a bad thing for work but not giving the option is also bad (probably the compromise is to have a field with "specified time period" so you can put a year on things if you are really sure you don't care
also would be important to stash this data on the relay for you to retrieve in an application specific data blob
also just pointing out, notifications don't have to be a specific event type, it is just a filter that polls for events and flips a toggle when a match comes up
"communities" is not a singular reason for notifications nor is anything... DMs are a commonly needed one, and focus topics and focus threads are others, so there's quite a list of things that need to be watched for
I thought if all of this and a chat-like UX accounts for all of it. So far.
Did you account for someone wanting to see all notifications from multiple npubs in one view? Because I desperately want that. 😂
No, but I wonder if that's even necessary if:
1. You have less need of spinning up different npubs because you can partition your content consumption and publication across community. As in: I don't need to spin up a different npub for my posts about coding, design or music. I just post I'm different communities.
2. If you have seamless profile switching built-in. If I spin up a different npub, it's going to be for a company, organisation, music band, ... and I'd like to be able to not have all those notifications in my face over the weekend by default.
But, If you do really want everything at one glance, I'm not designing for that no. I'm designing for easy/fast access and management. That means having notifications and necessary sctions in the same app. That in turn means splitting things by noub by default.
Well, that's okay. Just means we'll need another app.
I've mentioned before that I'd like a notification app with settings for every channel. Could specify down to user, like with Teams. Then your group SysAdmin npub that autoposts from your build service always comes through and goes straight to the top with a ❗and the normal work account is suppressed outside of business hours.
there's an event kind for storing application data
Those repos are published in communities (👉 relays).
If you say yes to "issues" from "gitworkshoppers" you have what you describe, no?
relays as a blanket source is a possible mapping but it seems like an extremely broad net
I'm just saying it's a great (and computation-light) place to start before coming up with all sorts of computation-heavy algos.
Ah, I see. Took me a minute. Someone could have an app that let's them manage their various communities, including communities only they are a member of, as if they were topic channels. Then you could manually curate the content and settings of your devstuff channel, your foodstuff channel, your homeschooling channel, but also the private GitCitadel channel that you share with the whole team and the public BibleStudy channel that all your Christianity-interested frens and frenemies are in and the semi-public GoDevs channel that you share with Mleku and Fiatjaf.
Like Teams or Slack does.
Yup 💯
Okay, so that model has the
Community: group of npubs≥1 defined by some relationship or topic
Channel: communication definition for the community, minimum one channel per community
One person/entity may have more than one npub and they may reside in different channels, but they can all be managed within one community-viewer, with community interaction limited to the npubs defined for that particular channel
I guess, then the only interaction that doesn't take place within a channel is DMs, right? Everything else would ideally be allocated. Or are DMs just in "Personal Channel for Npubbunchofnumbers", along with a little private notepad, list of articles to read, mailbox settings, etc.?
Yeah, if I have a DM chat with my wife, there's no reason why it could not also have our family calendar, Collab docs, music, movies, ...
Even just for yourself it can be seen as a community of one.
Seeing things as relays/communities all the way down is the easiest way to let normies handle and understand all this. Myself very much included.
We're all used to that format from our current apps.
I can see how Nostr adds value to that, over something like Teams or Slack, as we don't have to tie one user to one account. They can see everything together and we allow them to select one of the predefined accounts for that channel when signing.
there is nothing computation heavy about crafting filters to match a notification configuration, incredibly light, not even much memory
What is an issue btw?
In terms of event kind and content? A reply with markdown or sth?
you need to think more abstractly about what a person might want to be notified about
an issue is a post, that is tied to an event that you created the root of, it tags the event and thus you would set up a filter that looks for events that tag roots (repos) that you want to monitor, and possibly, not ones of people you have muted
and mutes, they are so broad, you may not want to read someone's war and peace posts on demand in your issues but usually enjoy their long form posts, for example
so, notification engines need to be complex by nature, highly configurable, with sensible defaults that don't give you notification fatigue too quickly... and temporary ignores that can quickly be set up when you need to focus, generally, or just not see some particular thing
Yeah, it is a repo-tagging note, that are commonly used to file bug reports or feature requests. So, I find it sort of annoying that I'm currently not being interrupted in my chit-chat about lasagne recipes by
~~~
User npubbunchofnumbers just posted the issue on your GitCitadel repo:
"Hey, help! Tried to use Alexandria and all I see is a 404 error! My colleagues all see the same error!"
~~~
Like. That might be important. Please interrupt me with that. Please. Please.
Whereas a feature request like "Would be nifty if Alexandria automatically generated a clickable index for every longer collection. 🤔 " is interesting, but right now I want to talk about lasagna.
Letting users decide usually ends up with everything being labeled a bug, since those get instant responses. So, you'd need AI to analyze and auto-label the content.
yes, don't let users dictate your feature set that much... put em on a triage until it makes sense
btw, repo posts in UI should render markdown
but also put render markdown over normie ui at compose post
Accidentally posted it under the wrong repo, at first, sorry.
Love red dots. 🤩
The value added for Nostr is that all the apps agree, more or less, on the underlying data structure. So a standalone notification app makes sense. It lets you preview and prioritize incoming notifications, then open and interact with the content in whatever specialized app is the best fit.
Non-Nostr apps can't really do that. At best you have to wrangle a bunch of different logins and unique APIs for all of your apps.
It's like the Windows notification center, but you can take it anywhere (especially if you can access the notifications tool as a web or mobile dashboard).
Notifications specifically targeted at you come down to:
- replies
- zaps
- shares
- mentions
- DM's
- requests with a yes/no answer
That's 99% of it and to handle these things I don't want to open another app (for replying, reacting, zapping, ...).
For opening newly published types of content that's high signal to you, the "open with app XXX" scenario makes way more sense.
A lot of it comes down to messages not having:
1. A target audience
2. A price
Once they do, determining which messages you're willing to miss out gets a lot easier.
Yes, targeting and price are essential. That's why I always read my zap notes. They paid to say that!
work related is always important... sometimes coworkers are annoying but mostly they go through phases, if it gets bad it's not hard to show an administrator and get this person pulled into line
Still lots of experimentation. My hunch is that ‘better social media’ though the first use case, might not be the killer use case. For me, I’m exploring new possibilities- likely 99% are duds for compelling use cases, but you never know.
Thinking that way is something developers have to be trained to do. I know because I'm that way. We have an expansive toolset and we love doing cool things with our tools, even if it doesn't really help anyone else.
Product teams are important, for that reason. Devs need to hear from UX and product/business minded people to stay balanced.
Yeah, they get caught up in the classic dilemma of having a cool, new hammer and wanting to treat everything as a nail. I get it.
And, as much as I hate to say it, the same goes for Bitcoin. Only the most rabid Bitcoiners will move here, just for the native Bitcoin integration. And a lot of people actually don't like Bitcoin.
Most "normie" Bitcoiners know that the apps they are currently using will eventually use Bitcoin because everyone will eventually use it. And they don't mind spending fiat, so long as they have some or can convert at PoS. Which they all can, now.
Allow monies to compete and/or allow for conversion at PoS. Don't make "use only my favorite money" your main feature. That is not a feature, it is a limitation.
I was trying to think of why I'm constantly so disappointed in the overall product quality and I think I have an explanation:
I'm often one of the app's first Real Users ™️ . And I immediately start using it to solve some specific problem. And then I hit a Workflow Wall because the devs didn't realize that someone would ever do
Those Damn Steps In That Damn Order To That Ridiculous Purpose.
They have one specific "happy path" and I veer off that path within 30 seconds and end in a swamp. But the way I was going was a perfectly sensible way and no path should end in a swamp.
Think through your happy and sad paths!
And, when I complain -- err, when I report a bug -- don't respond with "User Error", realize the precise opposite:
I just gave you a hint about a missing workflow or feature, that would raise the value added.