Improve readability by splitting long lines in README
- **readme.adoc**: - Split long bullet points into shorter lines for improved formatting and readability - Adjusted line breaks in technical descriptions (e.g., CGO configuration, database storage location) - Ensured consistent line wrapping across documentation sections
This commit is contained in:
46
readme.adoc
46
readme.adoc
@@ -12,14 +12,13 @@ and https://github.com/fiatjaf/relayer[fiatjaf/relayer] aimed at maximum perform
|
|||||||
|
|
||||||
== Features
|
== Features
|
||||||
|
|
||||||
* new HTTP REST API available in addition to standard websocket access, simplifying writing applications and tools, and building a standard API method set for future extensions for more flexible features.
|
|
||||||
* a lot of other bits and pieces accumulated from nearly 8 years of working with Go, logging and run control, XDG user data directories (windows, mac, linux, android) (todo: this is mostly built and designed but not currently available)
|
* a lot of other bits and pieces accumulated from nearly 8 years of working with Go, logging and run control, XDG user data directories (windows, mac, linux, android) (todo: this is mostly built and designed but not currently available)
|
||||||
* 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). (todo: HTTP API not in this repo yet but coming soon TM)
|
* 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). (todo: HTTP API not in this repo yet but coming soon TM)
|
||||||
* AVX/AVX2 optimized SHA256 and SIMD hex encoder
|
* 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]).
|
* 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, can tolerate whitespace, at a speed penalty)
|
* efficient, mutable byte slice-based hash/pubkey/signature encoding in memory (zero allocation decode from wire, can tolerate whitespace, at a speed penalty)
|
||||||
* custom badger based event store with an optional garbage collector that uses fast binary encoder for storage of events.
|
* custom badger-based event store with an optional garbage collector that uses fast binary encoder for storage of events.
|
||||||
* 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.
|
* 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
|
* 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.
|
* link:https://github.com/nostr-protocol/nips/blob/master/98.md[nip-98] implementation with new expiring variant for vanilla HTTP tools and browsers.
|
||||||
|
|
||||||
@@ -29,7 +28,8 @@ If you just want to make it run from source, you should check out a tagged versi
|
|||||||
|
|
||||||
The commits on these tags will explain what state the commit is at.
|
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).
|
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.
|
Go 1.24 or better is required.
|
||||||
|
|
||||||
@@ -46,19 +46,21 @@ Tags are in standard Go semver pattern `vX.X.X`
|
|||||||
== CGO and secp256k1 signatures library
|
== CGO and secp256k1 signatures library
|
||||||
|
|
||||||
By default, Go will usually be configured with `CGO_ENABLED=1`.
|
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.
|
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.
|
There is instructions in link:p256k/README.md[p256k/README.md] for doing this.
|
||||||
|
|
||||||
=== Disabling CGO
|
=== 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.
|
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
|
export CGO_ENABLED=0
|
||||||
go build .
|
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.
|
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
|
=== Static build
|
||||||
|
|
||||||
@@ -68,7 +70,8 @@ To produce a static binary, whether you use the CGO secp256k1 or disable CGO as
|
|||||||
go build --ldflags '-extldflags "-static"' -o ~/bin/orly .
|
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).
|
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
|
== Configuration
|
||||||
|
|
||||||
@@ -84,7 +87,8 @@ orly env
|
|||||||
|
|
||||||
=== Create Persistent Configuration
|
=== Create Persistent Configuration
|
||||||
|
|
||||||
This output can be directed to the profile location to make the settings editable without manually setting them on the commandline:
|
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
|
orly env > $HOME/.config/orly/.env
|
||||||
@@ -92,31 +96,39 @@ orly env > $HOME/.config/orly/.env
|
|||||||
|
|
||||||
You can now edit this file to alter the configuration.
|
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 does not use a complicated scheme, a simple library that allows automatic configuration of a series of options, added a simple info print:
|
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
|
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.
|
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
|
=== 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. Note that this is now available through the link:#_simplified_nostr[Simplified Nostr] HTTP OpenAPI endpoint on `/nuke`
|
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
|
== API support
|
||||||
|
|
||||||
=== Standard Nostr NIPs
|
=== 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.
|
`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]
|
||||||
=== Simplified Nostr
|
=== Simplified Nostr
|
||||||
|
|
||||||
NOTE: this is not currently implemented. coming soon TM
|
NOTE: this is not currently implemented. coming soon TM
|
||||||
|
|
||||||
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.
|
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.
|
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 does not require a websocket upgrade to work with.
|
There is even a subscription endpoint, also, which uses SSE format and doesn't require a websocket upgrade to work with.
|
||||||
Reference in New Issue
Block a user