chore: Add CONTRIBUTING.md, AUTHORS and DCO files

Signed-off-by: Awiteb <a@4rs.nl>

CONTRIBUTING.md

@@ -0,0 +1,86 @@
+# Contributing to `n34`
+
+For basic information about the `n34` project, please read the
+[README.md](README.md). The project is licensed under **GPL-3.0**, and by
+contributing, your work will also be licensed under the same terms.
+
+Before submitting changes, please read the [Developer Certificate of Origin](DCO).
+All patches must include a `Signed-off-by: NAME <EMAIL>` line to acknowledge
+your agreement with the DCO.
+
+We welcome all contributions, whether it be bug reports, fixes, feature
+submissions, feature requests, or improving documentation or testing. Enjoy
+collaborating!
+
+## Git Repository
+
+The repository is hosted at <https://git.4rs.nl/awiteb/n34.git>, with `master`
+as the active development branch.
+
+## Nostr Repository Address
+
+You can submit issues and patches via any
+Nostr-compatible client using the address:
+`naddr1qqpkuve5qgsqqqqqq9g9uljgjfcyd6dm4fegk8em2yfz0c3qp3tc6mntkrrhawgrqsqqqaueq
+yf8wumn8ghj7mn0wd68yt35wfejumnvqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7mn0wd68ytn00
+p68ytnyv4mqwuj6xc`
+
+## Contribution Workflow
+
+Before submitting changes, open an issue to discuss your proposed contribution.
+Clearly indicate that you intend to work on it and wait for a maintainer's
+response. If the issue remains open, you may proceed with submitting your patch.
+
+### Reporting Issues
+
+When opening an issue, include:
+- Detailed steps to reproduce the problem
+- Relevant error messages or logs (use the `-vvvv` flag for verbose output)
+- Expected vs. actual behavior
+
+Please label your issue appropriately (e.g., `bug`, `feature`, `question`) to
+help categorize it.
+
+### Your Patch
+
+Ensure your patch submission tool notifies the maintainers and sends the patch
+to their read relays, most tools handle this automatically.
+
+#### Patch Guidelines
+
+- Keep patches small: Focused changes are easier to review and merge.
+- Use [Conventional Commits]: Start the patch subject with one of these types:
+  - `feat`: New feature
+  - `fix`: Bug fix
+  - `docs`: Documentation updates
+  - `refactor`: Code restructuring without behavioral changes
+  - `deprecate`: Marking code as deprecated
+  - `remove`: Removing deprecated code
+  - `security`: Security-related changes
+  - `perf`: Performance improvements
+  - `test`: Test additions or corrections
+- For all other changes, use `chore`.
+- Add `!` to the subject if your patch contains a breacking change, e.g.
+`remove!: text` and `fix(reply)!: text`
+- Run `just ci` before submitting your patch.
+
+#### Code Style
+
+When writing code, make sure to folow this:
+- Using Rust's official formatting tool, `rustfmt`, to format your code.
+- Writing clear and concise code with meaningful variable and function names.
+- Adding comments to explain complex logic or algorithms.
+
+#### Cover Letter Description
+
+Your patch description should provide a clear and concise summary of the changes you
+have made. It should also include any relevant context or background information
+that will help the project maintainers understand the purpose of the changes.
+Make sure to reference the issue[^1] that your patch is addressing, and note any breaking
+changes that your patch introduces.
+
+
+
+[^1]: When referencing, avoid URLs or `nevent` formats with relays. Instead, use only the note ID in `note1` bech32 format.
+
+[Conventional Commits]: https://www.conventionalcommits.org/en/v1.0.0/