Topic: Damus
This subnote will be used for jotting down ideas for damus so I don't forget
Discussion
Instead of dropping into the chatroom by default, let's stick with the thread view, and change the expanded thread view to the chatroom. The expanded thread view is awkward and complicated anyways.
Should I create a new root note instead of subnotes? I think this is ok for now.
One interesting thing to note, if I only reference the subnotepad, then it won't get fetched when you pull the root notepad! Might be useful?
testing notepad link: #[0]
Topic: Editing
It would be cool if there was a way to edit notes. Basic idea: a note is created with the following tags:
```json
{"tags": [["e","thread_id"],["e","note_id","","edit"]]}
```
Where `note_id` is the note you are editing. Clients can replace the note with the most recent one it sees. It is able to fetch all edit notes because of the thread_id reference.
For clients that don't support this, it will look like a regular reply.
edits will have replace the entire note, not just content, because an edit might have references to pubkeys, events.
Editing an edit note should be invalid, an edit always references the original note it's editing. I think this makes the most sense.
Deleting
Deleting posts could work in a similar way, with a "delete" tag at the 3rd index instead of "edit"
Edits that look like replies sounds messy.
How about using parameterized replaceable events with `[d,event_id]`? It would not preserve the edit history but that's probably a feature.
Topic: Mentioned Notes and Reposts
When referencing notes, clients should be mindful to not interpret any "e" tag as a reply. For example, if there is a reference to an "e" tag in the content: #\[0] then this is not a reply, but a mention.
If there is a single event mentioned, clients may interpret this as a Mentioned Note, aka "Quote Retweet".
#[2] pointed out that this implies you could implement "retweets" simply by setting the content to '#\[0]', referencing a single note.
oops, don't have edit events yet, but that mention was supposed to be at #[2]
This is somewhat informal for now but in branle-like apps if there are more than two e tags, first one should be the thread root and last one should be an immediate reply. middle e tags for note mentions.
Without this the way tags are interpreted will vary greatly and that might be bad for interop. But this simple rule is very powerful and allows you to pull the full thread and mentions.
Topic: Bugs
Here are some bugs I still need to fix
Thread Unsubscribing
I just realized the reason I'm not instantly seeing the reply after a post. When you open the reply screen it triggers the onDisappear on the thread view, unsubscribing from the thread. This is the same bug where a thread gets unsubscribed when you switch from chat view to thread view.
We need a better way to handle thread unsubscriptions.
This is fixed now finally... need to implement delete 😑
NavigationLinks getting reset when events binding changes
Anytime the core events model gets changed, the TimelineView gets rerendered, destroys the nested NavigationLink, and pops you out of the thread.
This happens on the notification events binding as well when you get a new notification.
Should I pull the nested NavigationLinks all the way back to the top? Or maybe there is another issue at play...
You also get popped out from thread view back to chat room, so I guess there is a similar issue with the nested NavigationLink going from chat to thread. This is the is_thread thing in ThreadView
ThreadView has been causing so many issues, perhaps these are all related.
All fixed finallyyy
Image Uploading
Some great ideas gathered from nostr users so far:
- s3 bucket
- imgur api
- nextcloud support
I could try to make a company and product around damus so that image uploads are supported out of the box and funded eventually.
yeah this is what I was thinking about. and also with interoperability, so the user can switch hosting services/domain without breaking all their past posted content. like a redirect address in their profile that all clients agree to reference..?
Maybe add https://github.com/stakwork/sphinx-meme to your list for access control further down the road.
Restricted replies
This would be good for the collaborative document use cases. There should be a way to mark an event to restrict replies to a specific set of pubkeys or pubkey contacts, so that randos can't spam my public notepad.
Hiding replies
You should be able to send a special note as a reply that marks a reply to be hidden. This is really useful for people you want to mute in a particular thread.
Local Thread Search feature
It should be pretty easy to do a local search on whatever notes are loaded in the current thread/chat. Handy for notepads!
This makes me think I should be supporting tags on posts...
Add tags when posting notes
To help with local search and filtering, it would be cool if damus supported adding tags when posting. These could be hashtags ala [NIP12](https://github.com/fiatjaf/nostr/blob/master/nips/12.md) or something else.
Users can than filter on certain tags for users. If they only want to follow a users posts about bitcoin for example, you could tag the post with bitcoin.
Advanced Features
- Send to specific relay. This is pretty hardcore, as most people wouldn't want to think about it, but some notes might be preferred to stay on specific relays.
We might want to mark certain relays as private so that replies to them don't get broadcasted to public relays?
Group DMs
perhaps a room_key could be generated automatically by sha2(creator_sec_key+room_id). then the creator could invite people without needing to swap passwords?` to join you just need the room_id + room_key. seems simple enough... you could deliver a room invite (room_key and room_id) over an encrypted DM. this means anyone in the group could invite as well since they all have the room_key. just what I got off the top of my head.
Favourite Follows
Add an "f" tag to contacts that specifies "favourite follows". These users could be pinned to the top of you follow lists with a star. Maybe even have a comment field:
["f","pubkey","this guy is funny"]
cc #[3] this is more of a fun one I thought of, just giving you a heads up.
This would be in addition to the p tag for this pubkey as well of course. I couldn't think of any way to add it to the p tag or content. This would also allow you to query favourites across the network with #nip12 which might be interesting.
I like this. are you envisioning just using kind 3 or a new kind? I kinda like a new kind as you could use it for other lists, not just favorite lists. then people can make a single fav follows list or multiple lists of follows for different topics
Hmm good point... might be interesting as a new kind. I just like that 3 already has replacement logic on relays.
maybe favs go in kind 3 and the lists are a new kind? tbh I still don't know how the relay in the tag is used
then again fav follows could be in kind 3 and other lists are a new kind. might make more sense?