Skip to content

Commit

Permalink
README update
Browse files Browse the repository at this point in the history
  • Loading branch information
mikedilger committed Dec 11, 2023
1 parent cb939e4 commit c929047
Show file tree
Hide file tree
Showing 3 changed files with 82 additions and 69 deletions.
148 changes: 80 additions & 68 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,13 +36,13 @@ scoop install gossip

The following features make gossip different than most other nostr clients so far:

- **Desktop Portable**: Gossip is designed to run on desktop computers, and is portable to Windows, MacOS and Linux.
- **Desktop**: Gossip is designed to run on desktop computers, and runs on Windows, MacOS and Linux.
- **Gossip Model**: The Gossip Model was named after this client, because gossip never used a simple list of relays. From day one it tried to find posts of people that you follow wherever they are most likely to be, based on those people's relay lists as well as half a dozen other heuristics. Today multiple clients use a similar model, focused around ([NIP-65](https://github.com/nostr-protocol/nips/blob/master/65.md)). Gossip connects to all relays necessary to cover everybody you follow, while also trying to listen to the minimum number of relays necessary to do that (considering that there is overlap, and that people generally post to multiple relays). It also dynamically adjusts to relays being down or disconnecting.
- **Secure Key Handling**: Gossip handles private keys as securely as reasonable (short of hardware tokens), keeping them encrypted under a passphrase on disk, requiring that passphrase on startup, and zeroing memory. This shouldn't really be a point of difference but few other clients bother.
- **Avoids Browser-Tech**: Gossip avoids web technologies (other than HTTP GET and WebSockets which are necessary for nostr). Web technologies like HTML parsing and rendering, CSS, JavaScript and the very many web standards, are complex and represent a security hazard due to such a large attack surface. This isn't just a pedantic or theoretical concern; people have already had their private key stolen from other nostr clients. We use simple OpenGL-style rendering instead. It's not as pretty but it gets the job done.
- **Secure Key Handling**: Gossip handles private keys as securely as reasonable (short of hardware tokens), keeping them encrypted under a passphrase on disk, requiring that passphrase on startup, and zeroing memory before freeing it. This shouldn't really be a point of difference but few other clients bother.
- **Avoids Browser-Tech**: Gossip avoids web technologies (other than HTTP GET and WebSockets which are necessary for nostr). The web stack is huge, complex, and probably full of undiscovered vulnerabilities, presenting as a huge attack surface. This includes Javascript, the very many and ever-expanding set of web technologies built into browsers and accessible via javascript, and even HTML parsing, rendering, and CSS. This isn't just a pedantic or theoretical concern; people have already had their private key stolen from other nostr clients. We use simple OpenGL-style rendering instead. It's not as pretty but it gets the job done.
- **Performant**: Gossip aims towards being highly performant, using the LMDB database, the rust language, and coding architectures with performance always in mind. Unless you have quite old hardware, the network speed will probably be your bottleneck.
- **High user control**: Gossip has (at the time of writing) 57 different settings. When the right value is uncertain, I pick a reasonable default and give the user the mechanism to change it.
- **Privacy Options**: in case someone wishes to remain secret they should use Gossip over Tor - I recommend using QubesOS do to this. But you could use Whonix or even Tails. Don't just do it on your normal OS which won't do Tor completely. Gossip provides options to support privacy usage such as not loading avatars, not necessarily sharing who you follow, etc. We will be adding more privacy features.
- **High user control**: Gossip has (at the time of writing) 64 different settings. When the right value is uncertain, I pick a reasonable default and give the user the mechanism to change it.
- **Privacy Options**: in case someone wishes to remain secret they should use Gossip over Tor - I recommend using QubesOS do to this. But you could use Whonix or even Tails. Don't just do it on your normal OS, because on a plain OS sometimes data leaks around Tor (things like DNS lookups). Gossip supports using native TLS certificates so you can configure trust for .onion sites. Gossip provides options to support privacy usage such as not loading avatars, not loading images, not necessarily sharing who you follow, etc.

## Media

Expand All @@ -53,53 +53,63 @@ The following features make gossip different than most other nostr clients so fa

### nostr features supported

- [x] NIP-01 - Basic protocol flow description
- [x] NIP-02 - Contact List and Petnames
- [ ] NIP-03 - OpenTimestamps Attestations for Events [NOT PLANNED]
- [ ] NIP-04 - Encrypted Direct Message [Read Only is implemented]
- [x] NIP-05 - Mapping Nostr keys to DNS-based internet identifiers
- [ ] NIP-06 - Basic key derivation from mnemonic seed phrase
- [ ] NIP-07 - window.nostr capability for web browsers [NOT APPLICABLE]
- [x] NIP-08 - Handling Mentions
- [x] NIP-09 - Event Deletion
- [x] NIP-10 - Conventions for clients' use of e and p tags in text events
- [x] NIP-11 - Relay Information Document
- [x] NIP-13 - Proof of Work
- [x] NIP-14 - Subject tag in text events
- [x] NIP-18 - Reposts
- [x] NIP-19 - bech32-encoded entities
- [x] NIP-21 - nostr: URL scheme
- [x] NIP-22 - Event created_at Limits
- [ ] NIP-23 - Long-form Content [Optional viewing, but not creating]
- [ ] NIP-24 - Extra metadata fields and tags
- [x] NIP-25 - Reactions
- [x] NIP-26 - Delegated Event Signing
- [x] NIP-27 - Text Note References
- [ ] NIP-28 - Public Chat
- [ ] NIP-30 - Custom Emoji
- [x] NIP-31 - Dealing with Unknown Events
- [ ] NIP-32 - Labeling
- [x] NIP-36 - Sensitive Content
- [ ] NIP-39 - External Identities in Profiles
- [ ] NIP-40 - Expiration Timestamp
- [x] NIP-42 - Authentication of clients to relays
- [ ] NIP-45 - Counting results
- [ ] NIP-46 - Nostr Connect
- [x] NIP-48 - Proxy Tags
- [ ] NIP-50 - Keywords filter
- [ ] NIP-51 - Lists
- [ ] NIP-52 - Calendar Events
- [ ] NIP-53 - Live Activities
- [ ] NIP-56 - Reporting
- [x] NIP-57 - Lightning Zaps
- [ ] NIP-58 - Badges
- [x] NIP-65 - Relay List Metadata
- [ ] NIP-72 - Moderated Communities
- [ ] NIP-78 - Application-specific data
- [ ] NIP-89 - Recommended Application Handlers
- [ ] NIP-94 - File Metadata
- [ ] NIP-98 - HTTP Auth
- [ ] NIP-99 - Classified Listings
✅ = Fully Supported
🟩 = Partly Supported
⬜ = Not Supported (but might be in the future)
⬛ = Not Applicable

- ✅ NIP-01 - Basic protocol flow description
- ✅ NIP-02 - Contact List and Petnames
- ⬜ NIP-03 - OpenTimestamps Attestations for Events
- 🟩 NIP-04 - Encrypted Direct Message (Read Only is implemented)
- ✅ NIP-05 - Mapping Nostr keys to DNS-based internet identifiers
- ⬜ NIP-06 - Basic key derivation from mnemonic seed phrase
- ⬛ NIP-07 - window.nostr capability for web browsers (NOT APPLICABLE)
- ✅ NIP-08 - Handling Mentions
- ✅ NIP-09 - Event Deletion
- ✅ NIP-10 - Conventions for clients' use of e and p tags in text events
- ✅ NIP-11 - Relay Information Document
- ✅ NIP-13 - Proof of Work
- ✅ NIP-14 - Subject tag in text events
- ⬜ NIP-15 - Nostr Marketplace (for resilient marketplaces)
- ✅ NIP-18 - Reposts
- ✅ NIP-19 - bech32-encoded entities
- ✅ NIP-21 - nostr: URL scheme
- 🟩 NIP-23 - Long-form Content (Optional viewing, but not creating)
- 🟩 NIP-24 - Extra metadata fields and tags (Shown in profile, not treated specially)
- ✅ NIP-25 - Reactions
- ✅ NIP-26 - Delegated Event Signing
- ✅ NIP-27 - Text Note References
- ⬜ NIP-28 - Public Chat
- ⬜ NIP-30 - Custom Emoji
- ✅ NIP-31 - Dealing with Unknown Events
- ⬜ NIP-32 - Labeling
- ✅ NIP-36 - Sensitive Content
- ⬜ NIP-38 - User Statuses
- ⬜ NIP-39 - External Identities in Profiles
- ⬜ NIP-40 - Expiration Timestamp
- ✅ NIP-42 - Authentication of clients to relays
- ⬜ NIP-45 - Counting results
- ⬜ NIP-46 - Nostr Connect
- ⬜ NIP-47 - Wallet Connect
- ✅ NIP-48 - Proxy Tags
- ⬜ NIP-50 - Search Capability
- 🟩 NIP-51 - Lists
- ⬜ NIP-52 - Calendar Events
- ⬜ NIP-53 - Live Activities
- ⬜ NIP-56 - Reporting
- 🟩 NIP-57 - Lightning Zaps
- ⬜ NIP-58 - Badges
- ✅ NIP-65 - Relay List Metadata
- ⬜ NIP-72 - Moderated Communities
- ⬜ NIP-75 - Zap Goals
- ⬜ NIP-78 - Application-specific data
- ⬜ NIP-84 - Highlights
- ⬜ NIP-89 - Recommended Application Handlers
- ⬜ NIP-90 - Data Vending Machines
- ⬜ NIP-94 - File Metadata
- ⬜ NIP-98 - HTTP Auth
- ⬜ NIP-99 - Classified Listings

## Building from Source

Expand All @@ -123,9 +133,9 @@ Most dependencies are probably already installed in your base operating system.
- build essentials like gcc and make (debian: "build-essential")
- cmake (debian: "cmake")
- pkg-config (debian: "pkg-config")
- openssl (debian: "libssl-dev")
- openssl (debian: "libssl-dev") (this is only needed if not compiling with feature "rustls-tls")
- fontconfig (debian: "libfontconfig1-dev")
- ffmpeg support (debian: libavutil-dev libavformat-dev libavfilter-dev libavdevice-dev libxext-dev libclang-dev)
- ffmpeg support (debian: libavutil-dev libavformat-dev libavfilter-dev libavdevice-dev libxext-dev libclang-dev) (this is only needed if compiling with feature "video-ffmpeg")

#### macOS

Expand Down Expand Up @@ -154,13 +164,13 @@ The output will be a binary executable in `target/release/gossip`

This binary should be portable to similar systems with similar hardware and operating system.

If you want a binary optimized for your exact processor with the newest CPU features enabled, and all gossip features enabled:
If you want a binary optimized for your exact processor with the newest CPU features enabled, and all gossip features enabled, do something more like this (for exact features to use, see the next section):

````bash
RUSTFLAGS="-C target-cpu=native --cfg tokio_unstable" cargo build --features=lang-cjk,video-ffmpeg --release
````

Everything gossip needs (fonts, icons) is baked into this executable. It doesn't need to find assets. So you can move it and run it from anywhere.
Everything gossip needs (fonts, icons) is baked into this executable. It doesn't need to find assets. So you can move the "gossip" binary and run it from anywhere.

To make the binary smaller,

Expand All @@ -179,20 +189,21 @@ strip ./target/release/gossip
./target/release/gossip
````

## Compile Options
## Compile Features

### TLS

Gossip uses rustls by default. This is an SSL library in rust, which gets compiled into the binary, meaning we won't have issues trying to find your system SSL library or system CA certificates. It also means:
Gossip has three options for TLS support:

- Gossip will fail to negotiate SSL with servers that don't have any strong ciphersuites. This is a feature, but not one that everybody wants.
- Gossip may not compile on hardware that the `ring` crypto library does not yet support.
1. Use rust-code and compiled in root certificates from webpki (feature 'rustls-tls')
2. Use rust-code, but use your system's root certificates (feature 'rustls-tls-native', this is the default)
3. Use your system's code and your system's root certificates (feature 'native-tls')

If you wish to switch to your native TLS provider, use the following compile options:
Rust's TLS code is thought to be more secure than your systems TLS code (e.g. OpenSSL). But it is very finnicky. In particular:

````
--no-default-features --features=native-tls
````
- It will not accept self-signed CA certificates. If you have these on your system, it won't run at all.
- Gossip will fail to negotiate SSL with servers that don't have any strong ciphersuites. This is a feature, but not one that everybody wants.
- Gossip may not compile on hardware that the `ring` crypto library does not yet support.

### Language Support

Expand Down Expand Up @@ -222,7 +233,7 @@ Compile with

### Performance issues

If you are having performance issues, please see [PERFORMANCE.md](docs/PERFORMANCE.md).
If you are having performance issues, please see [docs/PERFORMANCE.md](docs/PERFORMANCE.md).

### Upgrading from very old versions

Expand All @@ -236,6 +247,7 @@ If you are using a version before 0.8.x, you must upgrade to a 0.8.x version and
- Tungstenite websocket library
- Tokio async task runtime
- Serde serialization/deserialization
- Speedy serialization/deserialization
- Many others

## License
Expand All @@ -248,9 +260,9 @@ All contributions welcome, please check the [development guidelines](docs/DEVELO

Please join [Gossip Telegram Channel](https://t.me/gossipclient).

Anyone interested in replacing the GUI with something much better, or keeping it as egui but making it much better, would be greatly appreciated.
Anyone interested in replacing the GUI with something much better, or keeping it as egui but making it much better, would be greatly appreciated. The project was split into two crates (lib and bin) to make it easier to build a different UI onto the backend.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, shall be licensed as above, without any additional terms or conditions.
Any contribution intentionally submitted for inclusion in the work by you, shall be licensed as above, without any additional terms or conditions.

## On Nostr

Expand All @@ -268,6 +280,6 @@ npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c

You can also my NIP-05 address of `[email protected]` which will also hook you up with the relays I post to.

I'd prefer if you trusted `[email protected]` higher than my public key at this point in time since key management is still pretty bad. That is the inverse of the normal recommendation, but my private key has not been treated very carefully as I never intended it to be my long-term keypair (it just became that over time). Also, I fully intend to rollover my keys once gossip supports the key-rollover NIP, whatever that is (or will be).
I'd prefer if you trusted `[email protected]` higher than my public key at this point in time since key management is still pretty bad. That is the inverse of the normal recommendation, but my private key has not been treated very carefully as I never intended it to be my long-term key pair (it just became that over time). Also, I fully intend to rollover my keys once gossip supports the key-rollover NIP, whatever that is (or will be).

You can tip me at my Bitcoin Lighting address: <[email protected]> == lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhkgetrv4h8gcn4dccnxv563ep
2 changes: 1 addition & 1 deletion docs/PERFORMANCE.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ This issue will be ameliorated somewhat in the future when you can have differen

### Non-Optimized Compile

Gossip should be compiled in release mode. You can also compile it for your individual processor to squeeze out the most performance (the following line leaves out feature flags, you'll wnat to determine which ones are right for you):
Gossip should be compiled in release mode. You can also compile it for your individual processor to squeeze out the most performance (the following line leaves out feature flags, you'll want to determine which ones are right for you):

````bash
RUSTFLAGS="-C target-cpu=native --cfg tokio_unstable" cargo build --release
Expand Down
1 change: 1 addition & 0 deletions gossip-bin/src/ui/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1754,6 +1754,7 @@ impl GossipUi {
response
}

// This function is to help change our subscriptions to augmenting events as we scroll.
fn handle_visible_note_changes(&mut self) {
let no_change = self.visible_note_ids == self.next_visible_note_ids;
let scrolling = self.current_scroll_offset != 0.0;
Expand Down

0 comments on commit c929047

Please sign in to comment.