0.7-SNAPSHOT branch

[tcheeric]

Nick @avlo, this is a major refactoring, an attempt to rectify some of the bad initial design decisions, reduce the size of the codebase, and hopefully make it better. It's still work in progress, but the code compiles without error, and the test cases have been adjusted accordingly.
I would appreciate your opinion, suggestions, critique etc, when you have time, as it may also have an impact on SC.

Here are the major changes:

1. I wanted to get rid of the impl classes in the API, they are not needed. See NIP01 re-implementation.
2. Instead, I am introducing a GenericEventFactory and GenericTagFactory, to create GenericEvents and GenericTags
3. Removed the now redundant BaseTag (or rather, merged it with the GenericTag)
4. To add support for a tag, you have to specify it in the tags.properties (base module) by providing its code, the list of its attribute names, and its corresponding nip
5. To implement a custom tag subclass, you need to add its json serializer class, and a static converter fromGenericTag method. This is useful. (see PubKeyTag class example)
6. Similarly, to implement a custom event subclass, a static fromGenericEvent method is also helpful (see TextNoteEvent) but json serializer is not needed.
7. Kinds are now integers. (this makes more sense and was overdue)
8. Still need to merge the changes recently pushed in the develop branch

Thanks.

[avlo]

@tcheeric hi, eric. thx for the inclusion & your description reads well. pulling down the changes shortly to review the implementation and will get back to you soon.

[avlo]

@tcheeric hi, eric.

attempting 0.7-SNAPSHOT_wip branch build, getting errors in NIP60.java & NIP61.java (screenshot below, w/ relevant commands executed/highlighted), looks like their internal classes commented out:

Amount
SpendingHistory
NutZap
NutZapInformation

are still referenced throughout NIP60 and NIP61 code. a quick uncommenting of them gets the build working, however, per your discussion topic here i'm guessing their exclusion/commented-state is intentional as per your refactoring goals.

if i've perhaps overlooked something, pls advise- otherwise likely a 'git add/commit/push' on your end should resolve any discrepancies and ensure i'm looking at your intended branch state.

[avlo]

@tcheeric hi, eric. supplemental to above: quick comparison of 0.7-SNAPSHOT_wip branch against nostr-java develop branch shows 395 files changed:

~/git/avlo-nostr-java-fork(0.7-SNAPSHOT_wip)$ git diff --name-only upstream-develop |wc -l
    395  
~/git/avlo-nostr-java-fork(0.7-SNAPSHOT_wip)$

w/ diff file between the two branches nearly ~23K lines long:

~/git/avlo-nostr-java-fork(0.7-SNAPSHOT_wip)$ git diff upstream-develop | wc -l
    23009
~/git/avlo-nostr-java-fork(0.7-SNAPSHOT_wip)$

containing ~7K lines of actual changes:

~/git/avlo-nostr-java-fork(0.7-SNAPSHOT_wip)$ git diff --unified=0 upstream-develop | grep -Po '(?<=^\+)(?!\+\+).*'|wc -l
    7352
~/git/avlo-nostr-java-fork(0.7-SNAPSHOT_wip)$

so exceedingly likely your repo 0.7-SNAPSHOT_wip branch is:

1. not in the same state as your local 0.7-SNAPSHOT_wip branch
   and/or
2. 0.7-SNAPSHOT_wip branch hasn't yet merged nostr-java develop branch into it

[tcheeric]

Hi nick, I think I know what the problem is. They weren't added to git. I'll fix that in a couple of hours.

[avlo]

gotcha, sounds good

[avlo]

just did a quick re-read & saw your bullet point #8 (develop branch changes not yet merged into 0.7-SNAPSHOT_wip). given the extensive updates/upgrades/refactors in develop branch and significant diff (as metric'd in above message) between the two branches, if you haven't already considered starting with develop branch current state and apply your refactor to it, as the MRCA between the two is Feb 15:

$ git merge-base 0.7-SNAPSHOT_wip upstream-develop
06407989fd09c39591b99dbdaf9d12577756fff8

$ git show 06407989fd09c39591b99dbdaf9d12577756fff8
commit 06407989fd09c39591b99dbdaf9d12577756fff8
Merge: e3023681 8ff8bb7e
Author: Eric T <tchepane_github@tutamail.com>
Date:   Sat Feb 15 15:37:08 2025 +0000

    Merge pull request #195 from avlo/req_message-validation
    
    Req message validation

in either case, when that merge is complete i'll be happy to take a look at the resulting implementation/diffs.

[tcheeric]

Absolutely. I will start working on that merge today.

[tcheeric]

Nick, I have now completed the merge of the develop and 0.7-SNAPSHOT branches. However, I am facing some issues with deserialising the new Filters and need help. It seems to be the same error causing 20 errors and Failures.

PS: I had to reoganise the class structure, and in addition, I have also removed the event module, and merged encryption-04 and encryption-44 modules.

[avlo]

@tcheeric gotcha, can you push a branch containing the filters failure to your repo and I'll get a look at it in the AM.

there are also example Filters/Filterables usages in ApiEventTest, JsonParseTest & FiltersDecoder/FiltersEncoder if useful/helpful in the meanwhile.

[tcheeric]

I've pushed the changes already, but I'll take a look as well again, thanks.

[avlo]

Nick, I have now completed the merge of the develop and 0.7-SNAPSHOT branches. However, I am facing some issues with deserialising the new Filters and need help. It seems to be the same error causing 20 errors and Failures.

PS: I had to reoganise the class structure, and in addition, I have also removed the event module, and merged encryption-04 and encryption-44 modules.

the error messages i'm seeing are constrained to EntityFactory.java and it's newly dependent classes (see below), not Filters. please send/post your compilation errors.

[INFO] Reactor Summary for nostr-java 0.7-SNAPSHOT:
[INFO] 
[INFO] nostr-java ......................................... SUCCESS [  0.402 s]
[INFO] nostr-java-util .................................... SUCCESS [  2.590 s]
[INFO] nostr-java-crypto .................................. SUCCESS [  3.339 s]
[INFO] nostr-java-base .................................... SUCCESS [  3.393 s]
[INFO] nostr-java-entities ................................ SUCCESS [  4.210 s]
[INFO] nostr-java-id ...................................... SUCCESS [  0.636 s]
[INFO] nostr-java-client .................................. SUCCESS [  1.092 s]
[INFO] nostr-java-encryption .............................. SUCCESS [  0.723 s]
[INFO] nostr-java-api ..................................... SUCCESS [  2.831 s]
[INFO] nostr-java-examples ................................ SUCCESS [  1.642 s]
[INFO] nostr-java-test .................................... FAILURE [  1.143 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  22.234 s
[INFO] Finished at: 2025-03-02T09:54:53-08:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.13.0:compile (default-compile) on project nostr-java-test: Compilation failure: Compilation failure: 
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[9,22] package nostr.entities does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[10,22] package nostr.entities does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[11,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[12,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[13,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[14,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[15,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[16,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[17,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[18,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[19,33] package nostr.entities.event.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[20,31] package nostr.entities.tag.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[21,31] package nostr.entities.tag.impl does not exist
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[155,19] cannot find symbol
[ERROR]   symbol:   class UserProfile
[ERROR]   location: class nostr.test.EntityFactory
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[41,23] cannot find symbol
[ERROR]   symbol:   class EphemeralEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[49,23] cannot find symbol
[ERROR]   symbol:   class DirectMessageEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[57,93] cannot find symbol
[ERROR]   symbol:   class UserProfile
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[57,23] cannot find symbol
[ERROR]   symbol:   class InternetIdentifierMetadataEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[64,23] cannot find symbol
[ERROR]   symbol:   class MentionsEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[80,57] cannot find symbol
[ERROR]   symbol:   class UserProfile
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[80,23] cannot find symbol
[ERROR]   symbol:   class MetadataEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[85,23] cannot find symbol
[ERROR]   symbol:   class ReactionEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[91,23] cannot find symbol
[ERROR]   symbol:   class ReplaceableEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[96,23] cannot find symbol
[ERROR]   symbol:   class TextNoteEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[101,23] cannot find symbol
[ERROR]   symbol:   class TextNoteEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] /home/nick/git/avlo-nostr-java-fork/nostr-java-test/src/main/java/nostr/test/EntityFactory.java:[107,23] cannot find symbol
[ERROR]   symbol:   class OtsEvent
[ERROR]   location: class nostr.test.EntityFactory.Events
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <args> -rf :nostr-java-test
~/git/avlo-nostr-java-fork(0.7-SNAPSHOT_wip)$ 

[avlo]

@tcheeric hi, eric. am i assuming correctly that 07-SNAPSHOT_wip will (upon completion) continue to pass all existing unit and integration tests? develop branch currently 159 tests, all passing:

whereas current state of 07-SNAP has clobbered/overwritten (not merged) changes to develop applied since their MRCA (Feb15) in blind/force-merge fashion, breaking both build and tests and even reintroducing code that has previously been removed.

with a bit of work i've been able to get 07-SNAP to build after which Filters tests passed without need for any changes, however more concerning, i've discovered the new GenericMessageDecoder.decode() for events is now broken, no longer properly recognize an events various tag types, lumping them all in as GenericTag rather than their specific (EventTag, PubKeyTag, etc) which is concerning as possibly additional/unintended breakages have been introduced as well.

as i believe i've got a good understanding of what your refactor goals are, i would like propose i do a proper/surgical refactor (neither breaking any existing functionality, nor tests) to properly integrate your architectural/design changes for:

BaseMessage -> GenericMessage
BaseTag -> GenericTag (without polymorphism loss introduced in 07-SNAP)
Kind (works fine as per 07-SNAP Integer implementation)

and request that 07-SNAP is not merged into develop branch prior to reviewing my alternate submission.

[avlo]

@tcheeric supplemental to above:

my variant will also include your new implementations for:

NIP44.java
NIP44Impl.java
NIP60.java
NIP61.java
NIP61Impl.java
NIP04Event.java
NIP08Event.java
Amount.java
NutZap.java
NutZapInformation.java
SpendingHistory.java

including your variants to:

NIP<XYZ>.java

classes, along with your new module / project-module restructuring:

nostr-java-api/
nostr-java-base/
nostr-java-client/
nostr-java-crypto/
nostr-java-encryption/
nostr-java-entities/
nostr-java-examples/
nostr-java-id/
nostr-java-test/
nostr-java-util/

[tcheeric]

Thank you for that!

[avlo]

@tcheeric hi, eric. do you have a working/uncommented variant of EventTagTest or working equivalent for any other class extending GenericTag? the 07-SNAP variants of those classes are failing when calling GenericTag#getFieldValue() and is hindering merge completion.

[tcheeric]

Hi Nick,

This has been deprecated in my 0.7-snap because of point 4 in the original post.

I now spec the tags in a property file and store the tag attributes in the element attributes data structure. It's a different approach I think was needed with the generic tags, whereas the other approach was more appropriate for concrete tags.

I hope this answers your question. Lmk what you think.

Can you share your branch with me so I can have a look?

Cheers.

[avlo]

super, even better, thx & should have the remaining merge done within a day or so (assuming no other roadblocks/unforseens/etc)

[tcheeric]

Oki. Ping me anytime if there is anything I can help with -- Secured with Tuta Mail: https://tuta.com/free-email 6 Mar 2025, 19:35 by ***@***.***:

…

super, even better, thx & should have the remaining merge done within a day or so (assuming no other roadblocks/unforseens/etc) — Reply to this email directly, > view it on GitHub <#201 (reply in thread)>> , or > unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQMG7BGRVDCZK6GANZWJK32TCPQXAVCNFSM6AAAAABYDPRYA2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBRHAYTIMY>> . You are receiving this because you were mentioned.> Message ID: > <tcheeric/nostr-java/repo-discussions/201/comments/12418143> @> github> .> com>

[avlo]

thx, will do and per your above request, will push a snapshot of the merged branch soon/sometime today

[avlo]

@tcheeric hi, eric. in-progress branch 07-SNAPSHOT_merge_fixes current merge-fix state, noteworthy:

• this is a manual merge ~80% done, currently working through remaining NIP<XX>.java classes and should be done tomorrow
• classes with naming pattern <XYZ>RxR.java are temporary placeholders for manually merged classes that were incomplete/broken in the 07-SNAP branch (you can get a count/view by running command $ find . -name *RxR.java).
• once merge is complete, all <XYZ>RxR.java classes will replace their original classes & properly renamed as per 07-SNAP classes names
• 07-SNAP directory structure is mostly in place, a few minor tweaks for that are coming up
• modules removed in 07-SNAP are also removed in this branch
• project compiles with unit test statuses as follows:

notes, as per your interest:

• AttributeUtil#getAttributeName(...) method has been refactored to return an Optional<String> rather than null, as extensively by java stream API in NIP01(RxR), GenericTagDeserializer(RxR) and <XYZ>Tag] classes
• code duplication in NIP01(RxR)`` and <XYZ>Tag classes have been streamlined and moved into their parent class.
• <XYZ>Tag class' fromGenericTag(...) methods have been updated with Functional methods, streamlining and simplifying each's implementation

after all tests are working again, there are a few other locations candidate for stream conversion as well. if you'd like to help, updating the remaining failing tests would be super helpful.

lastly, below file-name legend for non-obviously-named temporary files:
(temporary left, 07-SNAP right)

GenericTagAndBaseTag -> your GenericTag
BaseMessageDecoderRxR -> your GenericMessageDecoder

[avlo]

@tcheeric hi, eric. additional merge fixes pushed to 07-SNAPSHOT_merge_fixes branch, additional unit tests now passing (116 pass, 13 fail = 129 total):

looking into those now.

once they all pass, removing all pre-07-SNAP event/tag/message implementations (a simple delete-en-masse), then renaming all RxR files to their proper/07-SNAP names, after which i'll push another branch for us both to evaluate prior to submitting a formal PR to the develop branch.

suggestions, thoughts, ideas, concerns, etc are welcome as always.

[avlo]

@tcheeric hi, eric. ran into an issue i'm unable to configure/resolve/understand, whereby an addressable tag having parameterized replaceable format:

["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"],

specifically the:

"30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd"

portion is being (mis)interpreted as entirely kind:

and thus causing test failure. perhaps/likely the above format requires a tags.properties configuration that is missing? if so, hoping you can properly configure, as it appears to require nesting- which i'm uncertain (mainly, oblivious) of how to do. i've pushed a branch to your repo w/ the single unit test added, located here.

i'll work on this a bit tomorrow otherwise will take a break for the weekend as troubleshooting/debugging remaining test failures could definitely use a bit of stepping away / refresh for a bit.

[tcheeric]

Apologies for being silent. I have COVID and am still recovering...

[avlo]

no worries & no rush, hope you're feeling better soon, def can take some time to fully recover (2 weeks for me)

[avlo]

@tcheeric hi, eric. after a couple runs attempting integration of 07-SNAP_wip architectural changes to both nostr-java classes/consumers, i believe a slight architectural modification might cleanly enable 07-SNAP_wip refactor intention & rectify 07-SNAP_wip behavior-breaking while also maintaining existing nostr-java classes/APIs.

below diagram and accompanying branch develop-compositional_architecture demonstrate an alternate architecture to 07-SNAP_wip GenericTag implementation (labeled as 'EnumeratedGenericTag' here, just as distinctive placeholder) that should both serve your refactor purposes while still maintaining existing and desirably flexible BaseTag/GenericTag design & implementation:

code equivalent of above architecture (a compositional/decorator pattern) pattern preferable over inheritance in situations like ours), below:

(note: middle 'EnumeratedGenericTag' class is equivalent to your 07-SNAP_wip branch's GenericTag class)

if you can advise the proper git revision# of your work proceeding the "force-merge" with develop branch (should be prior to resultant 07-SNAP_wip branch), i'll:

1. integrate above architecture into that branch
2. apply Filters implementation already existing in develop branch to that revision
3. push a resultant branch for your candidate merge into develop branch.

ideas/questions/concerns welcome as always and hope you're feeling better, dude.

[tcheeric]

Hi nick, this looks good. I'll get you the information you need today. Regarding the issue with tag a, this is a special use-case due to the nature of the tag. I thought I had addressed it already, but apparently not...

[tcheeric]

hi nick,

3a52dd2043c0b45f580c27280dff926e80ee8bdb is the revision number for the initial commit into 0.7-snapshot on Feb 27 and e7cf3f5a274e843fa87948796d16bce732c27c77 was the force merge with develop. (Mar 1)

I hope this helps. Also, wouldn't it be easier for you to add your changes to the current develop branch?

Next, I am going to checkout your branch to reproduce the issue with the a-tag and will advise asap.

Thanks

[avlo]

awesome, thx & re: easier merging into develop... that is indeterminate/debatable as we'd still have the 07-SNAP_wip -> develop merge test failures (and the diff breakages causing them) to resolve which i'm hoping to avert for us both, unless you've perhaps already fixed?. lmk if so, otherwise i'll do a quick proof of concept of architectural adjustment to revision state prior to "force-merge". i'll keep you posted of that result then reintroduce remaining develop branch diffs from that point forward.

before starting that, per my earlier question above, re: tags.properties file (and companion GenericTag.create(...., Map<String, String>)Map parameter - what functionality/capability are you endeavouring to achieve (or perhaps a shortcoming to rectify?) by their introduction?

since enumerated values in tags.properties & counterpart GenericTag.create()#keys[i].toString() appear to be singly-and-exclusively used for an enumerated/static key at ElementAttribute[0] , it might be worthwhile to recall both events and requests containing generic tags are already handled by existing framework as-is (without hard-coding/enumerating a key-index string into ElementAttribute[0]), as that index/key is effectively discarded/rendered transient.

likewise for request filters containing any combination of all tag types- starting at the process triggered in ReqMessage.decode() with generic tag identification and processing in GenericTagQueryFilter.getPredicate(), you'll notice exclusive relevance of ElementAttributegetValue(), not getKey().

next, subsequent decoder handling of any tag type by FiltersDecoder.decode() via FilterableProvider.

if helpful/useful, implementation references / unit / integration tests for all the above in FiltersDecoderTest, ApiEventTest and incidentally, handling request filter lists as well- each containing generic tags- in ApiEventTest

[tcheeric]

before starting that, per my earlier question above, re: tags.properties file (and companion GenericTag.create(...., Map<String, String>)Map parameter - what functionality/capability are you endeavouring to achieve (or perhaps a shortcoming to rectify?) by their introduction?

tags.properties allows me to name and reference tags attributes. This is necessary when JSON-encoding tag objects. When dealing with an attribute, I need to know what it is so that I can place it in the JSON array.
Let me illustrate with the following example: consider the p-tag ["p", "023da9....", "Alice"] encoded as a GenericTag with two ElementAttributes (EA). To JSON-encode it, I need to know, when iterating through the EAs, whether the current EA is the pubkey or the pet-name.
This was obviously not a problem when dealing with concrete tag classes like PubkeyTag, but as I attempt to move more towards GenericTags, I thought this would be necessary.

since enumerated values in tags.properties & counterpart GenericTag.create()#keys[i].toString() appear to be singly-and-exclusively used for an enumerated/static key at ElementAttribute[0] , it might be worthwhile to recall both events and requests containing generic tags are already handled by existing framework as-is (without hard-coding/enumerating a key-index string into ElementAttribute[0]), as that index/key is effectively discarded/rendered transient.

OK, I think I understand. The List maintains the order (of course!), and therefore the above solution is unnecessary, correct? And the examples in your comment demonstrate it!

Re easier merging into develop, the suggestion was to start from a blank slate, and add the new code modifications there...?

On another note, the Filters new implementation is solid! Thanks for it.

[avlo]

OK, I think I understand. The List maintains the order (of course!), and therefore the above solution is unnecessary, correct?

yep! 💯🎯

And the examples in your comment demonstrate it!

👍👍

Re easier merging into develop, the suggestion was to start from a blank slate, and add the new code modifications there...?

i think so, yes- given our consensus that tags.properties design/approach is no longer necessary, that also renders both our architectural changes to GenericTag & BaseTag unnecessary as well- which clears you for NIP60/61/Impls and their various components (NostrWallet, NostrMint, etc) merge into develop branch (aka, the fresh/stable state) any time you're up for it.

On another note, the Filters new implementation is solid! Thanks for it.

yw 👍 simplicity of design & resultant flexible, resilient components (with built-in developer safeguards!) achievable via polymorphic thinkin'

---

re: project directory structure/module reorg, if you're ok with holding off on that for the moment as a spring/spring-boot -plus- gradle build tools upgrade to develop branch is underway.

it requires minimal (proper & conventional) test module setup/reconfiguration, with remaining modules/directory structures untouched, after which all nostr-java-<xyz> modules will not only be available as they currently- jars, but also as spring-boot-starters for pluggable/rapid development use.

---

a cleanup/fixes/modernization sweep has also been performed on therein, detailed as follows:

1. module-info.java files/handling no longer needed/necessary, thus removed. module dependencies now auto-management by spring.

2. 39 instances of runtime-reflection-heavy new ObjectMapper:

$ grep -Hnri 'new ObjectMapper' | wc -l
  39   <--------------------------------------------------------- before

replaced by 3 instances of compile-time-byte-code generated afterburner:

$ grep -Hnri 'new AfterburnerModule() | wc -l
  3     <--------------------------------------------------------- after

(tldr; afterburner is an efficiency improvement wrapper around ObjectMapper.

3. Encoder & FEncoder interfaces refactored into single Encoder interface, as all implementers of both use exactly the same mapper

4. pervasive null use(abuse!) refactored into Optional for performance increase and resiliency...

5. ...particularly in conjunction w/ java Stream API api (ongoing) and ...

6. ... declarative/procedural implementations updated/modernized for streaming & functional api

7. all pom transitive module dependency redundancies have been cleaned up, with noticeable maven build/test improvement... although i suspect you/others might opt for gradle after seeing these gradle-vs-maven performance metrics.

worth mentioning -> none of the above should affect your/others preferred development process and styles. seamless continuity is intended whereas "leveling up"/"modernizing" is intended as optional & available per developer choice/ready/need/etc.

[avlo]

supplemental, gradle install instructions

useful gradle commands (listed as aliases, w/ maven equivalents):

alias gc='gradle clean'  // 'maven clean' 
alias gb='gradle build'  // 'maven build'
alias gcb='gradle clean build' // 'maven clean build'

alias gbnotest='gradle build -x test'         // 'maven build -Dmaven.test.skip=true'
alias gcbnotest='gradle clean build -x test'  // 'maven clean build -Dmaven.test.skip=true'

alias gpub='gradle publishToMavenLocal'  // 'maven install'

[tcheeric]

Brilliant, thanks nick!