mleku
d2d2ea3fa0
- readme.adoc - Added a new "Releases" section with a link to pre-built binaries. - Included details about binaries built on Go 1.24 and Linux static builds.
176 lines
11 KiB
Plaintext
176 lines
11 KiB
Plaintext
= image:./docs/orly.png[orly.dev]
|
||
:toc:
|
||
:note-caption: note 👉
|
||
|
||
image:https://img.shields.io/badge/godoc-documentation-blue.svg[Documentation,link=https://pkg.go.dev/orly.lol]
|
||
image:https://img.shields.io/badge/donate-geyser_crowdfunding_project_page-orange.svg[Support this project,link=https://geyser.fund/project/orly]
|
||
zap me: ⚡️mlekudev@getalby.com
|
||
follow me on link:https://jumble.social/users/npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku[nostr]
|
||
|
||
nostr relay built from a heavily modified fork of https://github.com/nbd-wtf/go-nostr[nbd-wtf/go-nostr]
|
||
and https://github.com/fiatjaf/relayer[fiatjaf/relayer] aimed at maximum performance, simplicity and memory efficiency.
|
||
|
||
== Features
|
||
|
||
* a lot of bits and pieces accumulated from nearly 8 years of working with Go, logging and run control, XDG user data directories (windows, mac, linux, android)
|
||
* a cleaned up and unified fork of the btcd/dcred BIP-340 signatures, including the use of bitcoin core's BIP-340 implementation (more than 4x faster than btcd) (todo: ECDH from the C library tbd).
|
||
* AVX/AVX2 optimized SHA256 and SIMD hex encoder
|
||
* https://github.com/bitcoin/secp256k1[libsecp256k1]-enabled signature and signature verification (see link:p256k/README.md[here]).
|
||
* efficient, mutable byte slice-based hash/pubkey/signature encoding in memory (zero allocation decode from wire of all but id/pubkey/signature, can tolerate whitespace, at a speed penalty)
|
||
* custom badger-based event store that uses fast binary encoder for storage of events, and has a complete set of indexes so it doesn't need to decode events for any query until delivering them.
|
||
* link:cmd/vainstr[vainstr] vanity npub generator that can mine a 5-letter suffix in around 15 minutes on a 6 core Ryzen 5 processor using the CGO bitcoin core signature library.
|
||
* reverse proxy tool link:cmd/lerproxy[lerproxy] with support for Go vanity imports and https://github.com/nostr-protocol/nips/blob/master/05.md[nip-05] npub DNS verification and own TLS certificates
|
||
* link:https://github.com/nostr-protocol/nips/blob/master/98.md[nip-98] implementation with new expiring variant for vanilla HTTP tools and browsers.
|
||
|
||
== Releases
|
||
|
||
see link:https://github.com/mleku/orly/releases[Releases] for pre-built binaries built on latest stable Go 1.24. Linux binaries are built static and have no dependencies on `*.so` files on the host (so they can run on bare metal and in containers with nothing added).
|
||
|
||
== Building
|
||
|
||
If you just want to make it run from source, you should check out a tagged version.
|
||
|
||
The commits on these tags will explain what state the commit is at.
|
||
|
||
In general, the most stable versions are new minor tags, eg v1.2.0 or v1.23.0, and minor patch versions may not be
|
||
stable and occasionally may not compile (not very often).
|
||
|
||
Go 1.24 or better is required.
|
||
|
||
== Repository Policy
|
||
|
||
In general, the `main` branch will build, but occasionally may not.
|
||
It is where new commits are added once they are working, mostly, and allows people to easily see ongoing activity.
|
||
|
||
WARNING: IT IS NOT GUARANTEED TO BE STABLE... but it is getting there.
|
||
|
||
Use tags to pin to a specific version.
|
||
Tags are in standard Go semver pattern `vX.X.X`
|
||
|
||
== CGO and secp256k1 signatures library
|
||
|
||
By default, Go will usually be configured with `CGO_ENABLED=1`.
|
||
This selects the use of the C library from bitcoin core, which does signatures and verifications much faster (4x and
|
||
better) but complicates the build process as you have to install the library beforehand.
|
||
There is instructions in link:p256k/README.md[p256k/README.md] for doing this.
|
||
|
||
=== Disabling CGO
|
||
|
||
In order to disable the use of this, you must set the environment variable `CGO_ENABLED=0` and it the Go compiler will
|
||
automatically revert to using the btcec based secp256k1 signatures library.
|
||
|
||
----
|
||
export CGO_ENABLED=0
|
||
go build .
|
||
----
|
||
|
||
This will build the binary and place it in the root of the repository, and then you can move it where you like.
|
||
|
||
=== Static build
|
||
|
||
To produce a static binary, whether you use the CGO secp256k1 or disable CGO as above:
|
||
|
||
----
|
||
go build --ldflags '-extldflags "-static"' -o ~/bin/orly .
|
||
----
|
||
|
||
will place it into your `~/bin/` directory, and it will work on any system of the same architecture with the same glibc
|
||
major version (has been 2 for a long time).
|
||
|
||
== Configuration
|
||
|
||
The default will run the relay with default settings, which will not be what you want.
|
||
|
||
=== Show Current Configuration
|
||
|
||
To see the current active configuration:
|
||
|
||
----
|
||
orly env
|
||
----
|
||
|
||
To see the help information:
|
||
|
||
----
|
||
orly help
|
||
----
|
||
|
||
Environment variables that configure orly:
|
||
|
||
[cols="4"]
|
||
|===
|
||
| Environment variable | type | default | description
|
||
| ORLY_APP_NAME | string | orly |
|
||
| ORLY_CONFIG_DIR | string | ~/.config/orly | location for configuration file, which has the name '.env' to make it harder to delete, and is a standard environment KEY=value<newline>... style
|
||
| ORLY_STATE_DATA_DIR | string | ~/.local/state/orly | storage location for state data affected by dynamic interactive interfaces
|
||
| ORLY_DATA_DIR | string | ~/.local/cache/orly | storage location for the event store
|
||
| ORLY_LISTEN | string | 0.0.0.0 | network listen address
|
||
| ORLY_PORT | int | 3334 | port to listen on
|
||
| ORLY_LOG_LEVEL | string | info | debug level: fatal error warn info debug trace
|
||
| ORLY_DB_LOG_LEVEL | string | info | debug level: fatal error warn info debug trace
|
||
| ORLY_PPROF | string | <empty> | enable pprof on 127.0.0.1:6060
|
||
| ORLY_AUTH_REQUIRED | bool | false | require authentication for all requests
|
||
| ORLY_PUBLIC_READABLE | bool | true | allow public read access to regardless of whether the client is authed
|
||
| ORLY_SPIDER_SEEDS | []string | wss://profiles.nostr1.com/,
|
||
wss://relay.nostr.band/,
|
||
wss://relay.damus.io/,
|
||
wss://nostr.wine/,
|
||
wss://nostr.land/,
|
||
wss://theforest.nostr1.com/,
|
||
wss://profiles.nostr1.com
|
||
| seeds to use for the spider (relays that are looked up initially to find owner relay lists) (comma separated)
|
||
| ORLY_SPIDER_TYPE | string | directory | whether to spider, and what degree of spidering: none, directory, follows (follows means to the second degree of the follow graph)
|
||
| ORLY_SPIDER_FREQUENCY | time.Duration | 1h | how often to run the spider, uses notation 0h0m0s
|
||
| ORLY_SPIDER_SECOND_DEGREE | bool | true | whether to enable spidering the second degree of follows for non-directory events if ORLY_SPIDER_TYPE is set to 'follows'
|
||
| ORLY_OWNERS | []string | [] | list of users whose follow lists designate whitelisted users who can publish events, and who can read if public readable is false (comma separated)
|
||
| ORLY_PRIVATE | bool | false | do not spider for user metadata because the relay is private and this would leak relay memberships
|
||
| ORLY_WHITELIST | []string | [] | only allow connections from this list of IP addresses
|
||
| ORLY_SECRET_KEY | string | <empty> | secret key for relay cluster replication authentication
|
||
| ORLY_PEER_RELAYS | []string | [] | list of peer relays URLs that new events are pushed to in format <pubkey>\|<url>
|
||
|===
|
||
|
||
=== Create Persistent Configuration
|
||
|
||
This output can be directed to the profile location to make the settings editable without manually setting them on the
|
||
commandline:
|
||
|
||
----
|
||
orly env > $HOME/.config/orly/.env
|
||
----
|
||
|
||
You can now edit this file to alter the configuration.
|
||
|
||
Regarding the configuration system, this is an element of many servers that is absurdly complex, and for which reason
|
||
orly doesn't use a complicated scheme, a simple library that allows automatic configuration of a series of options,
|
||
added a simple info print:
|
||
|
||
----
|
||
orly help
|
||
----
|
||
|
||
will show you the instructions, and the one simple extension of being able to use a standard formated .env file to
|
||
configure all the options for an instance.
|
||
|
||
=== Database Storage Location
|
||
|
||
The database is stored in `$HOME/.local/share/orly` and if need be you can stop `orly` delete everything in this
|
||
directory and restart to "nuke" the database.
|
||
|
||
== API support
|
||
|
||
=== Standard Nostr NIPs
|
||
|
||
`orly` already accepts all the standard NIPs mainly nip-01, and many other types are recognised such an NIP-42 auth
|
||
messages and it uses and parses relay lists, and all that other stuff.
|
||
|
||
[#_simplified_nostr]
|
||
=== Simplified Nostr
|
||
|
||
Rather than write a text that will likely fall out of date very quickly, simply run `orly` and visit its listener
|
||
address (eg link:http://localhost:3334/api[http://localhost:3334/api]) to see the full documentation.
|
||
|
||
By default, this presents you with a Scalar Docs page that lets you browse the available API methods and shows examples
|
||
in many forms including cURL and most languages how to call and what data needs to go in headers, body, and parameters
|
||
and what results will come back.
|
||
|
||
There is even a subscription endpoint, also, which uses SSE format and doesn't require a websocket upgrade to work with. |