2023-10-30 03:14:50 +07:00
|
|
|
|
|
|
|
// Bostr config
|
|
|
|
|
|
|
|
module.exports = {
|
|
|
|
// Server listener [Required]
|
|
|
|
address: "0.0.0.0",
|
|
|
|
port: "8080",
|
|
|
|
|
2024-01-13 18:53:59 +07:00
|
|
|
// Standalone HTTPS server. Normally bostr is accepting unsecured connections.
|
|
|
|
// Specifying the absolute path of the private key/certificate will make bostr to only accept secured connections.
|
|
|
|
//
|
|
|
|
// Tip: You do not need this if you are running bostr behind reverse proxy.
|
2024-01-13 06:36:24 -05:00
|
|
|
https: {
|
|
|
|
privKey: "",
|
|
|
|
certificate: "",
|
|
|
|
ticketKey: ""
|
|
|
|
},
|
|
|
|
|
2024-05-10 14:59:00 +07:00
|
|
|
// Clusters (default: 1)
|
2024-05-10 14:53:05 +07:00
|
|
|
//
|
|
|
|
// Every single clusters has additional 1 running worker,
|
|
|
|
// Which making bostr running at 2 threads by default.
|
|
|
|
//
|
|
|
|
// You may increase this value if:
|
|
|
|
// - You want to use more threads/cores in your server
|
|
|
|
// - You got heavy traffics / many clients
|
2024-05-10 14:59:00 +07:00
|
|
|
// 0 (auto) will determine based of how many parallelism / cores available in the system.
|
|
|
|
clusters: 1,
|
2023-10-31 14:16:43 +07:00
|
|
|
|
2024-03-18 23:57:53 +07:00
|
|
|
// Numbers of idle sessions to be created
|
|
|
|
// Default: 1
|
|
|
|
idle_sessions: 1,
|
|
|
|
|
2024-01-13 06:36:24 -05:00
|
|
|
// Log about bouncer connection with relays?
|
2023-11-01 19:54:03 +07:00
|
|
|
log_about_relays: false,
|
|
|
|
|
2024-01-27 19:42:18 +07:00
|
|
|
// Use deflate compression for websocket.
|
2024-05-12 08:14:32 +07:00
|
|
|
// This could save user bandwidth.
|
2024-05-12 08:08:40 +07:00
|
|
|
perMessageDeflate: true,
|
2024-01-27 19:42:18 +07:00
|
|
|
|
2024-03-27 23:23:53 +07:00
|
|
|
// Reject scraper requests.
|
|
|
|
// This only checks whenever client respond to bouncer's AUTH.
|
|
|
|
//
|
|
|
|
// NOTE: - Require NIP-42 compatible nostr client.
|
2024-03-27 23:28:59 +07:00
|
|
|
// - This will also block unauthorized EVENT.
|
2024-04-11 20:32:19 +07:00
|
|
|
noscraper: false,
|
2024-03-27 23:14:09 +07:00
|
|
|
|
2023-12-19 12:05:11 +09:00
|
|
|
// Time before reconnect to relays in milliseconds.
|
2023-11-18 16:49:20 +07:00
|
|
|
reconnect_time: 5000,
|
|
|
|
|
2024-01-23 21:12:06 +07:00
|
|
|
// Ratelimit expiration after ratelimit from upstream relay in miliseconds.
|
|
|
|
// Setting as 0 will disable ratelimit handling.
|
|
|
|
upstream_ratelimit_expiration: 10000,
|
|
|
|
|
|
|
|
// Maximum subscriptions that client could open.
|
|
|
|
// Setting as -1 will disable max subscription limit.
|
|
|
|
max_client_subs: -1,
|
|
|
|
|
2024-05-11 13:44:25 +07:00
|
|
|
// Maximum Known Events
|
|
|
|
// Used for knowing what events has been forwarded to client in order to prevent duplicates to be forwarded.
|
2024-05-12 11:59:52 +07:00
|
|
|
// This is only storing event IDs into memory (RAM), not an entire event blob.
|
2024-05-11 13:44:25 +07:00
|
|
|
//
|
2024-05-11 19:04:15 +07:00
|
|
|
// Setting as 0 will store known events to memory without limit until the subscription is closed.
|
|
|
|
// Reduce this value if memory usage is high. But don't go too low as duplicates will be forwarded to client.
|
2024-05-11 19:06:22 +07:00
|
|
|
max_known_events: 5000,
|
2024-05-11 13:44:25 +07:00
|
|
|
|
2023-11-21 18:42:04 +07:00
|
|
|
// Wait for every connected relays send EOSE.
|
2023-12-19 12:05:11 +09:00
|
|
|
// Could improve accuracy on received events.
|
2023-11-21 18:42:04 +07:00
|
|
|
//
|
|
|
|
// Depending on your configured relays,
|
|
|
|
// It may could cause loading problems in client due to slow EOSE from bouncer.
|
2023-11-22 16:38:46 +07:00
|
|
|
// You could try fix this by changing <eose_timeout> or <max_eose_score> value.
|
|
|
|
wait_eose: true,
|
2023-11-21 18:42:04 +07:00
|
|
|
|
2023-11-21 20:49:14 +07:00
|
|
|
// Pause an subscription from receiving further events after reached to <filter.limit>
|
2024-04-11 12:51:20 +07:00
|
|
|
// Enabling this could fix bandwidth issues at certain client.
|
2024-02-27 18:00:19 +07:00
|
|
|
// This is also known as save mode.
|
2023-11-21 18:42:04 +07:00
|
|
|
//
|
2024-01-31 20:58:14 +07:00
|
|
|
// You may also need to adjust <max_eose_score>.
|
2024-04-11 12:48:21 +07:00
|
|
|
pause_on_limit: false,
|
2023-11-21 18:42:04 +07:00
|
|
|
|
2023-11-22 16:38:46 +07:00
|
|
|
// Maximum of received EOSE from relays to send EOSE to client.
|
|
|
|
// Normally, waiting EOSE from 3 relays should be enough. Leaving it with 0 equals wait for every established relays.
|
|
|
|
// NOTE: Please adjust this max score correctly with your configured relays.
|
|
|
|
// If you only setted up 3 relays, Set the <max_eose_score> as 0.
|
2023-11-22 16:51:46 +07:00
|
|
|
// Tip : The bigger = The more accurate EOSE, The less = EOSE sent way earlier.
|
2023-12-28 08:38:00 +07:00
|
|
|
max_eose_score: 0,
|
2023-11-22 16:38:46 +07:00
|
|
|
|
2023-11-20 21:21:22 +07:00
|
|
|
// A whitelist of users public keys who could use this bouncer.
|
2024-01-01 11:16:53 +07:00
|
|
|
// Leaving this empty will allow everyone to use this bouncer.
|
|
|
|
// NOTE: - Require NIP-42 compatible nostr client.
|
|
|
|
// You may use <allowed_event_authors> instead if your client does not support NIP-42.
|
2023-11-16 21:53:58 +07:00
|
|
|
authorized_keys: [
|
|
|
|
// "pubkey-in-hex",
|
|
|
|
// "npub ....",
|
|
|
|
// ....
|
|
|
|
],
|
|
|
|
|
2024-04-05 14:24:45 +07:00
|
|
|
// A whitelist of allowed event owner.
|
|
|
|
// Leaving this empty will allow everyone to publish events from anyone to this bouncer.
|
|
|
|
allowed_publishers: [
|
2024-01-01 11:16:53 +07:00
|
|
|
// "pubkey-in-hex",
|
|
|
|
// "npub ....",
|
|
|
|
// ....
|
2024-01-13 06:36:24 -05:00
|
|
|
],
|
2024-01-01 11:16:53 +07:00
|
|
|
|
2024-04-05 14:24:45 +07:00
|
|
|
// A blacklist of blocked event owner.
|
2024-02-27 18:13:56 +07:00
|
|
|
blocked_publishers: [
|
|
|
|
// "pubkey-in-hex",
|
|
|
|
// "npub ....",
|
|
|
|
// ....
|
|
|
|
],
|
|
|
|
|
2024-02-18 20:07:46 +07:00
|
|
|
// Block incomming websocket connections from the following hosts.
|
|
|
|
blocked_hosts: [
|
|
|
|
// "127.0.0.1",
|
|
|
|
// "127.0.0.2",
|
|
|
|
// "::1",
|
|
|
|
// "::2",
|
|
|
|
// ....
|
|
|
|
],
|
|
|
|
|
2023-11-20 21:21:22 +07:00
|
|
|
// Used for accessing NIP-42 protected events from certain relays.
|
2023-11-20 21:10:57 +07:00
|
|
|
// It could be your key. Leaving this empty completely disables NIP-42 function.
|
2023-11-20 21:21:22 +07:00
|
|
|
//
|
|
|
|
// You could use this function even as a public bouncer.
|
|
|
|
// There are no security risk as it utilize NIP-42 to recognize client public key.
|
|
|
|
//
|
|
|
|
// NOTE: - Require NIP-42 compatible nostr client
|
2023-11-16 21:53:58 +07:00
|
|
|
private_keys: {
|
2024-02-21 16:17:50 +07:00
|
|
|
// "pubkey-in-hex": "privatekey-in-hex",
|
2023-11-16 22:07:07 +07:00
|
|
|
// "pubkey-in-hex": "nsec ...."
|
2023-11-18 22:23:18 +00:00
|
|
|
},
|
2023-11-16 22:07:07 +07:00
|
|
|
// Tip: If you want to convert your pubkey/privatekey to hex,
|
|
|
|
// You could run the following command:
|
|
|
|
// $ node hexconverter.js npub....
|
|
|
|
// $ node hexconverter.js nsec....
|
2024-02-21 16:17:50 +07:00
|
|
|
// or
|
|
|
|
// $ bostr hexconverter npub....
|
|
|
|
// $ bostr hexconverter nsec....
|
2023-11-16 21:53:58 +07:00
|
|
|
|
2023-10-30 03:14:50 +07:00
|
|
|
// Server information.
|
|
|
|
// Only for when nostr client requesting server information.
|
|
|
|
server_meta: {
|
|
|
|
"contact": "unset",
|
2023-11-21 19:19:22 +07:00
|
|
|
"pubkey": "0000000000000000000000000000000000000000000000000000000000000000",
|
2023-11-19 08:02:40 +07:00
|
|
|
"description": "Nostr relay bouncer",
|
2023-10-30 03:14:50 +07:00
|
|
|
"name": "Bostr",
|
|
|
|
"software": "git+https://github.com/Yonle/bostr",
|
2023-11-12 16:54:39 +07:00
|
|
|
|
|
|
|
// Some nostr client may read the following for compatibility check.
|
2023-11-12 19:41:36 +07:00
|
|
|
// You may change the supported_nips to match with what your relays supported.
|
2023-11-18 22:23:18 +00:00
|
|
|
"supported_nips": [1,2,9,11,12,15,16,20,22,33,40,42,50],
|
2024-02-19 18:37:50 +07:00
|
|
|
// "icon_url": ""
|
2023-10-30 03:14:50 +07:00
|
|
|
},
|
|
|
|
|
2024-01-09 06:58:27 +07:00
|
|
|
// Path to favicon file.
|
|
|
|
favicon: "",
|
|
|
|
|
2023-10-30 03:14:50 +07:00
|
|
|
// Nostr relays to bounce [Required]
|
|
|
|
relays: [
|
|
|
|
"wss://example1.com",
|
|
|
|
"wss://example2.com",
|
|
|
|
// "wss://example3.com",
|
|
|
|
// ...and so on
|
2024-03-22 23:54:37 +07:00
|
|
|
],
|
2024-04-28 21:01:58 +07:00
|
|
|
// Unless you use this bouncer only for load balancing,
|
|
|
|
// You could empty <relays> as long <loadbalancer> is not empty.
|
2024-03-22 23:54:37 +07:00
|
|
|
|
|
|
|
// Cache relays - Store received events to cache relay(s) (Optional).
|
|
|
|
// Could improve the speed of event deliveries.
|
|
|
|
//
|
2024-03-23 12:11:16 +07:00
|
|
|
// Ensure that the cache relay does not have websocket ratelimit being set.
|
|
|
|
// CAUTION: - Cache relay is intensive in storing events.
|
2024-03-22 23:54:37 +07:00
|
|
|
// - Only works best with only 1 cache relay.
|
|
|
|
// - Things may not work properly if you configure more than just a single cache relays.
|
|
|
|
cache_relays: [
|
|
|
|
// "ws://localhost:3000"
|
2024-04-28 21:01:58 +07:00
|
|
|
],
|
|
|
|
|
|
|
|
// Load balancer - Load balance this bouncer (Optional)
|
|
|
|
//
|
|
|
|
// You could make this bouncer to connect to other bouncer in order to save this server loads.
|
|
|
|
// It's suggested that the following bouncers does not have `noscraper` or `authorized_keys` being set.
|
|
|
|
loadbalancer: [
|
|
|
|
// "wss://bostr1.example.com",
|
|
|
|
// "wss://bostr2.example.com",
|
|
|
|
// "wss://bostr3.example.com",
|
|
|
|
// ...and so on
|
2023-10-30 03:14:50 +07:00
|
|
|
]
|
|
|
|
}
|