Nostradamic vs Nostr-java #71

guilhermegps · 2023-07-12T12:55:51Z

guilhermegps
Jul 12, 2023
Collaborator

I was searching on internet and I found this article where the author talk a little about nostr-java.

Well, the author was really hard about Nostr-java, but there are some importants points. They said that "don't like it very much", but it was the only library available, so they made the following comments:

it uses lombock which has no future after Java introduced records (I used lombok in the past, but now it is obsolete)

too much inheritance in the domain model (this is a sin of the academic world - in real projects, the composition is preferred)

the way the project is structured, the maven sub-project is also not the best (it is better to be structured on NIPs)

in-house JSON encoder/decoder is needed?

Well, some points are really pertinents.

I'd like to know what everyone here thinks about it.

tcheeric · 2023-07-12T13:34:56Z

tcheeric
Jul 12, 2023
Maintainer

I have not read the full article yet, but I'll say this: 1) he's right about lombok 2) and 3) is interesting feedback and pertinent, indeed. 4) he's right about in-house json (and this what the latest release addresses) I'll probably have more to say after reading the article, and thanks for sharing. -- Sent with Tutanota, enjoy secure & ad-free emails. 12 Jul 2023, 13:56 by ***@***.***:

…

I was searching on internet and I found this > article <https://nostradamic.com/how-i-built-a-nostr-relay-with-java>> where the author talk a little about nostr-java. Well, the author was really hard about Nostr-java, but there are some importants points. They said that "don't like it very much", but it was the only library available, so they made the following comments: > > it uses >> lombock <https://github.com/fiatjaf?tab=repositories>>> which has no future after Java introduced records (I used lombok in the past, but now it is obsolete) > > > too much inheritance in the domain model (this is a sin of the academic world - in real projects, the composition is preferred) > > > the way the project is structured, the maven sub-project is also not the best (it is better to be structured on NIPs) > > > in-house JSON encoder/decoder is needed? > > Well, some points are really pertinents. I'd like to know what everyone here thinks about it. — Reply to this email directly, > view it on GitHub <#71>> , or > unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQMG7BMJLGPKJ5PR3AEQ6DXP2NGFANCNFSM6AAAAAA2HOLTYQ>> . You are receiving this because you are subscribed to this thread.> Message ID: > <tcheeric/nostr-java/repo-discussions/71> @> github> .> com>

0 replies

tcheeric · 2023-07-12T21:40:58Z

tcheeric
Jul 12, 2023
Maintainer

OK, just finished reading and I don't have much to add, but I'll say this:

The author makes some valid points, specifically points 1 and 4, as mentioned earlier today.

I had looked into java records and was undecided, but now I'm seriously considering adding it to the roadmap. I need to evaluate the work needed for that.
Using an in-house JSON library was definitely not a good move. It's like building your own hash algorithm, which is generally not recommended. The library was kind of working, but I was never comfortable with it, and I'm relieved that it has now been phased out.
Points 2 and 3 are more subjective, in my opinion, but I'll definitely look into them further, especially point 2. The comparison with the academic world made me smile, considering I have had quite a difficult relationship with university and I'm mostly self-taught.
I tend to disagree more with point 3, but I would have liked to hear the reasoning that led the author to their conclusion.

PS: I'm not bothered or feel insulted by the "don't like it very much." It sounds harsh, but I think it's honest, candid, and argued in good faith. Overall, it gives me a lot to think about in terms of improving the project.

0 replies

guilhermegps · 2023-07-13T19:40:35Z

guilhermegps
Jul 13, 2023
Collaborator Author

Hey buddy,

In my opinion, the most importants points was the 3 and 4 And I will explain why.

First point is half correct. I studied Java Records a little before to form a opinion and it's a really nice option for data representation classes, but it doesn't settle all problems that Lombok fix. In fact, We can read in JEP 359:

Records are a new kind of type declaration in the Java language. Like an enum, a record is a restricted form of class. It declares its representation, and commits to an API that matches that representation. Records give up a freedom that classes usually enjoy: the ability to decouple API from representation. In return, records gain a significant degree of concision.

...

Restrictions on records
Records cannot extend any other class, and cannot declare instance fields other than the private final fields which correspond to components of the state description. Any other fields which are declared must be static. These restrictions ensure that the state description alone defines the representation.

Records are implicitly final, and cannot be abstract. These restrictions emphasize that the API of a record is defined solely by its state description, and cannot be enhanced later by another class or record.

The components of a record are implicitly final. This restriction embodies an immutable by default policy that is widely applicable for data aggregates.

So, although records are an interesting way to reduce code, but it doesn't solve all the scenarios that Lombok works with. I recommend taking your time and only where it makes sense.

The second point is not a real problem.
As for points 3 and 4. In fact, the structure of the project we have today is really a bit confusing, organizing in NIPs would be better for sure. I don't need to comment on the "in-house JSON", right? We removed it as soon as possible.

8 replies

tcheeric Jul 14, 2023
Maintainer

I see, it looks very clean; there is less clutter when using the event factory!

tcheeric Jul 15, 2023
Maintainer

Hi @guilhermegps
I have created the nostr-java-api module in the 0.3-SNAPSHOT branch. It is a sort of facade for simplifying the creation of events, while still relying on the existing code.
Please have a look when you have a chance and let me know your thoughts.

Here's the client code for creating events:

    private static void send(Client client, String content) throws NostrException {

        // Get the sender's identity
        final Identity identity = Identity.getInstance();
        PublicKey sender = identity.getPublicKey();

        // Create the event
        var eventFactory = new Events.NIP01(sender, content);
        var event = eventFactory.createEvent();

        // Sign the event
        identity.sign(event);

        // Send the message
        client.send(event);
    }

Source: https://gist.github.com/tcheeric/490734ad95387719886f6389b2a8b3e6

guilhermegps Jul 18, 2023
Collaborator Author

Well, I think this doesn't settle the structure organization and centralize the operators in one module.

To restructure the project is almost the same that to remake it from scratch.

We don't need to worry about it now. The project needs other changes first.

The organization won't be a problem if we have a trustworthy and robust library.

Let's focus in to implement more NIPs, fix bugs and improve code.

tcheeric Jul 19, 2023
Maintainer

Well, I think this doesn't settle the structure organization and centralize the operators in one module.

Is centralisation not a consequence of the "separation of concerns"? Isn't that desirable? I agree with the rest of the points, but wouldn't the new module make it easier to use the library? Or do you think the effort required to implement it is not worth it?

guilhermegps Aug 9, 2023
Collaborator Author

Is centralisation not a consequence of the "separation of concerns"?

Actually, not.

Isn't that desirable?

I don't think so.

I agree with the rest of the points, but wouldn't the new module make it easier to use the library?

Maybe, but will it pay off?

Or do you think the effort required to implement it is not worth it?

I think that the best way would be to create multiples modules based in "separeted concerns". So that when someone wants to use a specific NIP, they will just import the minimal modules necessary for that.

This is about a better way to manager dependencies based on NIPs.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Nostradamic vs Nostr-java #71

Uh oh!

{{title}}

Uh oh!

Replies: 3 comments 8 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Select a reply

Uh oh!

Nostradamic vs Nostr-java #71

Uh oh!

guilhermegps Jul 12, 2023 Collaborator

Replies: 3 comments · 8 replies

Uh oh!

tcheeric Jul 12, 2023 Maintainer

Uh oh!

tcheeric Jul 12, 2023 Maintainer

Uh oh!

guilhermegps Jul 13, 2023 Collaborator Author

Uh oh!

tcheeric Jul 14, 2023 Maintainer

Uh oh!

tcheeric Jul 15, 2023 Maintainer

Uh oh!

guilhermegps Jul 18, 2023 Collaborator Author

Uh oh!

tcheeric Jul 19, 2023 Maintainer

Uh oh!

Uh oh!

guilhermegps Aug 9, 2023 Collaborator Author

guilhermegps
Jul 12, 2023
Collaborator

Replies: 3 comments 8 replies

tcheeric
Jul 12, 2023
Maintainer

tcheeric
Jul 12, 2023
Maintainer

guilhermegps
Jul 13, 2023
Collaborator Author

tcheeric Jul 14, 2023
Maintainer

tcheeric Jul 15, 2023
Maintainer

guilhermegps Jul 18, 2023
Collaborator Author

tcheeric Jul 19, 2023
Maintainer

guilhermegps Aug 9, 2023
Collaborator Author