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
Discussion
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.