Nostr View

https://cdn.satellite.earth/ac93c9c26c732d47fcf87ac886fd6d43fe72e750e555f48cbf00186fd5695c4b.mov Chat notification counters are great for DM's. They are not great for Groups and Communities. One counter for ANYTHING new that happens within a group is a horrible idea. Especially on Nostr, where you have way more than just chat messages ( 👉 posts, articles, videos, wikis, app releases, ... ). Instead, you'd need: 1. A way to keep track of stuff that directly targeted at you 🔔 2. The ability to select what new content types you want to get notified about 📕 🧵 🦋 #nostrdesign #notifications #chatmaxi #communities

Niel Liesmons @nielliesmons - 4mo

Since you can publish a video in multiple communities at once, you can also handle the notifications on that video from any of these selected communities. You'll see the notification counter go down simultaneously in the other communities. So you choose in what community you go and spend your time and attention while "handling" notifications from related communities at the same time as a byproduct.

Laeserin @Laeserin - 3mo

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.

⛩oizen @moizen - 3mo

muahaha that they got to play architect without skipping aesthetics and phenomenology courses

Laeserin @Laeserin - 3mo

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.

Laeserin @Laeserin - 3mo

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.

Laeserin @Laeserin - 3mo

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.

Laeserin @Laeserin - 3mo

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.

mleku ✝Ⓐ☯︎ @mleku - 3mo

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

Laeserin @Laeserin - 3mo

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.

Laeserin @Laeserin - 3mo

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!

mleku ✝Ⓐ☯︎ @mleku - 3mo

which is why working instant messaging should be a top priority

Laeserin @Laeserin - 3mo

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.

Niel Liesmons @nielliesmons - 3mo

That makes notifications UX even more important to nail.

mleku ✝Ⓐ☯︎ @mleku - 3mo

that's client side i'd argue that should be a standalone app, living in your system tray, running in the background

Niel Liesmons @nielliesmons - 3mo

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.

Niel Liesmons @nielliesmons - 3mo

Your notification app = Your daily driver

Laeserin @Laeserin - 3mo

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.

mleku ✝Ⓐ☯︎ @mleku - 3mo

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

mleku ✝Ⓐ☯︎ @mleku - 3mo

hell, i'd get a notification every minute or two and i only have 100 follows

mleku ✝Ⓐ☯︎ @mleku - 3mo

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

Niel Liesmons @nielliesmons - 3mo

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: nostr:nevent1qvzqqqqqqypzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qythwumn8ghj7un9d3shjt3s0p3ksct59e3k7mf0qy88wumn8ghj77tpvf6jumt99uqzqafhnzxvjkgtyjs4xsymdhda0308a8zaeapwvh86ms8ejkzuc3x5n6prce

Laeserin @Laeserin - 3mo

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.

mleku ✝Ⓐ☯︎ @mleku - 3mo

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

Niel Liesmons @nielliesmons - 3mo

Those repos are published in communities (👉 relays). If you say yes to "issues" from "gitworkshoppers" you have what you describe, no?

mleku ✝Ⓐ☯︎ @mleku - 3mo

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

Niel Liesmons @nielliesmons - 3mo

What is an issue btw? In terms of event kind and content? A reply with markdown or sth?

mleku ✝Ⓐ☯︎ @mleku - 3mo

relays as a blanket source is a possible mapping but it seems like an extremely broad net

mleku ✝Ⓐ☯︎ @mleku - 3mo

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

Niel Liesmons @nielliesmons - 3mo

I thought if all of this and a chat-like UX accounts for all of it. So far.

Laeserin @Laeserin - 3mo

there's an event kind for storing application data

Niel Liesmons @nielliesmons - 3mo

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.

Showing page 1 of 1 pages