Add nevent extension separate from matcher extension

[staab]

Just playing around with the code, trying to understand tiptap/prosemirror. One thing I would like is to be able to pick and choose which extensions get added, and to be able to configure each extension independently. To that end, I've created an nevent node, which uses tiptap's nodePasteRule. This code is much simpler, and seems to work just as well. Is this an approach you've considered? Are there any flaws with it? Just trying to understand how this all works so I can effectively contribute.

[cesardeazevedo]

Awesome, thanks a lot for the PR, I think your approach makes a lot more sense, since nostr links only makes sense as copy/paste events, and the current approach we call parseReferences on every key change, but we also need to be able to parse existing notes outside the editor.

I thought about this approach too where each extensions would have it's own logic, but I was initially was making the autolink work where a pasteRule wouldn't apply and I figure out I could replace everything at once in a single prosemirror transaction and I didn't want to duplicate the appendTransaction logic.

I really like the idea where nostr-editor provides the actual extensions implementation instead of instructing the users implement them, gonna take a deeper look.

[cesardeazevedo]

Doing some interesting progress here, we could heavily split the main NostrMatcherPlugin and rename it to just as a AutoLinkMatcher (as it was based from the remirror AutoLinkMatcher), and handle all nostr links in their respective extensions as just paste rules, and create a new extension specific for parsing existing notes where the code would be a lot simpler since we don't need to handle document range changes logic.

[staab]

What would it look like to use the editor to parse notes so I can try it out? Would addInputRules solve that? Or maybe parseHTML?

[cesardeazevedo]

Right now there's this file that I am about to eliminate in favor of a simple editor command a (addInputRules might also works, gonna take a look), it basically apply some changes in a transaction and return a new state.

You can also follow the unit tests here https://github.com/cesardeazevedo/nostr-editor/blob/main/src/__tests__/parser.test.ts

[cesardeazevedo]

Just pushed some changes in your branch together with some code that I had, I think your approach is good and we are can start doing the same approach for nprofile and naddr.

[staab]

Great, just pushed an update for naddr and nprofile. I also added support for npub and note within nprofile and nevent. Next, I want to add functionality for a suggestions popover when the user types @. I have that sort of working on Coracle so I should be able to bring it over pretty easy.

[staab]

Ok, just pushed a very rough version of profile suggestions. It would be nice to package in the main lib, but a lot of the complexity comes from integrating the framework, so I'm not sure the best way to do it.

[cesardeazevedo]

That's looking great, I initially thought about putting something in the package, but in the end, nostr-editor will be just a small handful extensions, adding abstractions around tiptap suggestions will just add unnecessary abstractions.

Do you know what nostr-editor could also be shipped with? or what is missing? I am still planning to deploy a small gitbook for documentation and some end to end tests with playwright.

[staab]

Here's what I'm shooting for:

• Profile/topic suggestions
• Inline code and code blocks support
• Cashu invoice parsing and QR display
• Possibly group/community/feed/list/note suggestions with custom triggers
• Note embeds are configurable by kind
• Paste parses things (differentiating between media and external links)
• Image upload via selection and drag and drop to a section in the note
• nsecs are recognized and rejected with UI feedback

How much of this should be in the library is totally debatable, especially since so much of the behavior will be application-specific. I do think an extension for building suggestions would be nice to have to guide developers with implementation, even if it's very minimal.

[cesardeazevedo]

Thanks, that looks a solid roadmap.

Just pushed some improvements on the profile suggestions component, and also moved the rest of the extensions to the library.

I also been thinking about "differentiating between media and external links" as way to build imeta tags when creating notes.

I am gonna merge this pr for now.