Repo Guidelines

NIPs

nostr-java is a java implementation of the nostr protocol. The specification is available on github, here: https://github.com/nostr-protocol/nips The URL format for the NIPs is https://github.com/nostr-protocol/nips/blob/master/XX.md where XX is the NIP number. For example, the specification for NIP-01 is available at the URL https://github.com/nostr-protocol/nips/blob/master/01.md etc.

When writing code, follow the "Clean Code" principles:
- Clean Code
  - Relevant chapters: 2, 3, 4, 7, 10, 17
- Clean Architecture
  - Relevant chapters: All chapters in part III and IV, 7-14.
- Design Patterns
  - Follow design patterns as described in the book, whenever possible.
When commiting code, follow the Conventional Commits specification.
When adding new features, ensure they are compliant with the Cashu specification (NUTs) provided above.
Make use of the lombok library to reduce boilerplate code.

Always run mvn -q verify from the repository root before committing your changes.
Include the command's output in the PR description.
If tests fail due to dependency or network issues, mention this in the PR.
Update the documentation files if you add or modify features.
Update the pom.xml file for new modules or dependencies, ensuring compatibility with Java 21.
Verify new Dockerfiles or docker-compose.yml files by running docker-compose build.
Document new REST endpoints in the API documentation and ensure they are tested.
Add unit tests for new functionality, covering edge cases. Follow "Clean Code" principles on unit tests, as described in the "Clean Code" book (Chapter 9).
Ensure modifications to existing code do not break functionality and pass all tests.
Add integration tests for new features to verify end-to-end functionality.
Ensure new dependencies or configurations do not introduce security vulnerabilities.
Add a comment on top of every test method to describe the test in plain English.

Always follow the repository's PR submission guidelines and use the PR template located at .github/pull_request_template.md.
Summarize the changes made and describe how they were tested.
Include any limitations or known issues in the description.
Ensure all new features are compliant with the Cashu specification (NUTs) provided above.