Definitely multiple identities. For me that's a slightly different but crucial use case.

I was thinking that authors tagging posts is the lowest friction way to do what you (as a reader) need them to so you can read about rust but not BTC.

An author's (self-defined) tags could be part of their profile.

An author's (self-defined) tags could be part of their profile.

I also think it would be great for private groups to separately create their own private nostr networks wherever and whenever they want. They would be separate from the wider, global nostr network like a LAN is separate from the interwebs, though using the same plumbing.

I really hope this isn't what the future of nostr looks like. It seems like a re-invention of a web forum.

What I hope nostr becomes is a global public commons; what twitter should have been but failed to be. It should definitely support ways for users to slice, dice, group, filter and make community. But it should also allow for an un-siloed connectivity between anyone and anyone and/or anyone and everyone.

I agree and I like this best because it keeps all the smarts in the clients and keeps the relays more agnostic.

Who knows how this will all evolve and what it will evoke from users in the future. I just have a feeling that configuring separate sets of relays for each different type of content that you want to post is going to feel cumbersome for most users. It feels cumbersome to me and I'm a geek. I think 1 might be the simplest / easiest solution but it limits you in ways that some people probably wouldn't like. I would certainly do that for some purposes, but I probably also want to be able to post as "me" about various topics without being someone else.

I think even my idea (3) is going to feel cumbersome to a lot of people who just want to type into a box and hit send. But I also think if the UI is simple enough and there is some peer pressure from followers it could fly.

But I also think this whole topic really depends a lot on the vision you have of nostr as a network going forward. My preferred vision has a big, interoperable fabric where organic "communities" might evolve based on follow lists (and probably follow of follow, etc. lists), but there are no hard and fast silos as could be implied with more purpose-driven relays as in 2 and your original post that made me think about usenet.

tags on notes and you follow not ust a user but a user plus some (sub)set of their tags?

Vitor, do take a look at unifiedpush (https://unifiedpush.org/). It's a very developer friendly, cross platform framework that lets you do decentralized push notifications outside of the grasp of tech titans. It has zero dependence on FCM or Apple services. It works amazingly well on Android with ntfy (https://github.com/binwiederhier/ntfy-android) which can be either hosted or self-hosted.

Here's a simple android unifiedpush integration example in their github: https://github.com/UnifiedPush/android-example

Yes, seems to be fixed on that commit. Thanks.

test (sorry!)

unified push is dev-friendly, cross-platform, awesome non-FCM push notifications. Sample android app integration on their github here: https://github.com/UnifiedPush/android-example

Crash happened when trying to reply to an event. Here's the stack trace (though guessing it's not super usable, or if it is, count me happily not a rust developer):

thread '' panicked at 'index out of bounds: the len is 0 but the index is 18446744073709551615', src/db/person_relay.rs:339:17

stack backtrace:

0: 0x10cdd1922 - __mh_execute_header

1: 0x10cdef2aa - __mh_execute_header

2: 0x10cdcb76c - __mh_execute_header

3: 0x10cdd16ea - __mh_execute_header

4: 0x10cdd2fd6 - __mh_execute_header

5: 0x10cdd2d27 - __mh_execute_header

6: 0x10cdd371d - __mh_execute_header

7: 0x10cdd34d3 - __mh_execute_header

8: 0x10cdd1db8 - __mh_execute_header

9: 0x10cdd319d - __mh_execute_header

10: 0x10ce34693 - __mh_execute_header

11: 0x10ce347d6 - __mh_execute_header

12: 0x10c4bb1d1 - __mh_execute_header

13: 0x10c50866d - __mh_execute_header

14: 0x10c4f53e6 - __mh_execute_header

15: 0x10c4c490a - __mh_execute_header

16: 0x10c3edc10 - __mh_execute_header

17: 0x10c46c13d - __mh_execute_header

18: 0x10c492380 - __mh_execute_header

19: 0x10c44a6f2 - __mh_execute_header

20: 0x10cdd5f07 - __mh_execute_header

21: 0x7ff8168404e1 - __pthread_start

Got this crash with 27121f4:

thread '' panicked at 'index out of bounds: the len is 0 but the index is 18446744073709551615', src/db/person_relay.rs:339:17

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

(I'll set up that env var and see if I can repro)

I'm also on graphene. I do have Google Play Services installed in the profile where I am using Amethyst but none of the google apps, frameworks, components have any network permissions so they will never be able to make any translation stuff available to Amethyst. I am not getting any crashes with recent versions of Amethyst (I stay up to date with github APK releases).

My plea is just to keep it like this in the future. Translation is a nice-to-have for me but for my purposes, it's way more important to not have Google in my life than to be able to read non-English notes.

Please just don't make the ability to DL translation data through Google a hard dependency for the app. Just let the whole translation machinery fail silently and gracefully (as I think it does now) if someone or other happens to be running Amethyst on a de-googled device.

Also, Amethyst is great.