Awesome
- What is NostrP2P?
- Consept and Design
- Technical Overview
- Build
- NostrP2P Command Usage
- Specification
- Examples
- Bootstrap Server
- Client
- Trial
- Roadmap (Server&Client)
What is NostrP2P?
- Pure Peer-to-Peer Distributed Microblogging System on NAT Transparent Overlay Network Based on Idea of Nostr
- Distributed Microblogging System by All User's Contribution
- I wrote an article about NostrP2P :)
Concept and Design
- here (English)
- English version is latest :)
- Japanese version
Technical Overview
Difference and Commpon Points with (General) Nostr
- Difference with (general) Nostr
- Server (Relay server)
- Firstly, in NostrP2P, servers communicate with each other on pure peer-to-peer manner. Clients does not
- This means that NostrP2P has client-server architecture also
- Servers of NostrP2P are correspond and similar to Relay server of Nostr but these are more distributed and coodinate with each other
- Servers handle each recieved event data in a different way though these are not special kind one (ex: replacable events) on Nostr because optimization for pure peer-to-peer network architecture is needed
- Supporse large number of servers because each user of NostrP2P need my server
- Client can trust server it accesses to
- This is important for optimization of client's network resource consumption and power consumption
- Powerful machine is not needed for server because it handles only one user's requests and amount of managing data is not large compred to (general) Nostr
- If we considered server (Relay server) as a kind of database system, above is obvious
- Firstly, in NostrP2P, servers communicate with each other on pure peer-to-peer manner. Clients does not
- Client
- Almost same role with one of Nostr but its communication protocol between server is little bit different
- In current plan, transport is REST and data is encoded to binary. Not websocket and Not JSON text
- Client which is used by User-A only accesses to a server which is managed by the user
- Almost same role with one of Nostr but its communication protocol between server is little bit different
- In all of design
- Microbrogging application specific
- This means architecture and protcorl of NostrP2P is not for general purpose unlike Nostr
- "Nostr" is a name of architecture and protocol and not name of SNS and Microblogging system
- In other words, "NostrP2P" is a name of an microblogging system like "Bluesky"
- This means architecture and protcorl of NostrP2P is not for general purpose unlike Nostr
- Microbrogging application specific
- Server (Relay server)
- Common point with (general) Nostr
- Data structure of event data is almost same
- Key pair format and signing method are same
- Specification like kind number is same if it is for same functionality (at least for now)
- Functionality realization led by Clients
- (flexibility may be low compared with general Nostr...)
(General) Nostr Architecture
classDiagram
RelayServerA <-- ClientX : Raed/Write
RelayServerA <-- ClientY : Raed/Write
RelayServerB <-- ClientX : Raed/Write
RelayServerB <-- ClientY : Raed/Write
RelayServerB <-- ClientZ : Raed/Write
RelayServerC <-- ClientX : Raed/Write
RelayServerC <-- ClientZ : Raed/Write
RelayServerD <-- ClientZ : Raed/Write
RelayServerD <-- ClientY : Raed/Write
namespace Internet {
class RelayServerA{
}
class RelayServerB{
}
class RelayServerC{
}
class RelayServerD{
}
}
class ClientX{
}
class ClientY{
}
class ClientZ{
}
NostrP2P Architecture
classDiagram
ServerA <|--|> ServerB : coodinate
ServerA <|--|> ServerC : coodinate
ServerA <|--|> ServerD : coodinate
ServerB <|--|> ServerC : coodinate
ServerB <|--|> ServerD : coodinate
ServerA <-- ClientA : Raed/Write
ServerB <-- ClientB : Read/Write
ServerC <-- ClientC : Read/Write
ServerD <-- ClientD : Read/Write(VPN)
namespace Internet {
class ServerA{
}
class ServerB{
}
}
namespace NW-C____________ {
class ServerC{
}
class ClientC{
}
}
namespace NW-D______________ {
class ServerD{
}
}
namespace NW-A {
class ClientA{
}
}
namespace NW-B_________ {
class ClientB{
}
}
namespace NW-X_________ {
class ClientD{
}
}
Build
$ go build -o nostrp2p main.go
NostrP2P Command Usage
Usage:
nostrp2p [flags]
nostrp2p [command]
Available Commands:
help Help about any command.
server Startup server.
genkey Generate new key pair.
Flags:
-h, --help Help for NostrP2P
Usage:
nostrp2p server [flags]
Flags:
-h, --help Help for server
-l, --listen-addr-port string Address and port to bind to (default: 127.0.0.1:20000)
-b, --boot-peer-addr-port string Address and port of a server which already joined NostrP2P network (optional)
-p, --public-key string Your public key (required)
-d, --debug bool If true, debug log is output to stderr (default: false)
Specification
Examples
Generate Key Pair
./nostrp2p genkey
Secret Key:
...
Secret Key (In Hex Representation):
...
Public Key:
...
Public key (In Hex Representation):
...
Server Launch
# 4 servers network on local network (4 shells are needed...)
./nostrp2p server -l 0.0.0.0:20000 -p <public key in npub format>
./nostrp2p server -l 0.0.0.0:20002 -p <public key in npub format> -b 127.0.0.1:20000
./nostrp2p server -l 0.0.0.0:20004 -p <public key in npub format> -b 127.0.0.1:20002
./nostrp2p server -l 0.0.0.0:20006 -p <public key in npub format> -b 127.0.0.1:20000
# 4 servers distributed on different networks
# on network ryogrid.net (bind to address/port which is accessible from The Internet)
./nostrp2p server -l 0.0.0.0:20000 -p <public key in npub format>
# on network redsky.social (bind to address/port which accessible from The Internet)
./nostrp2p server -l 0.0.0.0:7777 -p <public key in npub format> -b ryogrid.net:9999
# on network A (bind to address/port which is NOT accessible from The Internet)
./nostrp2p server -l 0.0.0.0:20000 -p <public key in npub format> -b ryogrid.net:8888
# on network B (bind to address/port which is NOT accessible from The Internet)
./nostrp2p server -l 0.0.0.0:20000 -p <public key in npub format> -b redsky.social:7777
Bootstrap Server
- Currently, running server which is accessible from The Internet is below
- ryogrid.net:8888
- this address including port number shoud be specified at launching of your server with -b option
- ryogrid.net:8888
- These servers don't response to write kind REST API requests from clients. A server for yourself is also needed to use NostrP2P!
Client
- here <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12325/9fce752c-3d73-fa48-10ea-0770330a3b38.png" height="65%" width="65%" />
Trial
Current Implemented Featues on Dedicated NW
- Please refer this article's Demo section :)
<del>Current Implemented Features with Nostr Client (Not NostrP2P Client) Using a Protcol Bridge Server</del>
- <del>Please read this</del>
Roadmap (Server&Client)
- Messaging on NAT Transparent Overlay Network
- Posting with Client
- Reaction
- Following
- Mention
- Reply
- Quote Repost
- Repost
- Server Side Signature Validation
- Restriction of Memory Usage on Server
- Data persistence on Server with embedded DB
- Follower Multicast Mode
- In this mode, posted messages are not broadcasted and server of follower should register to followee's server
- If broadcasting design reaches limit of scalability, this mode will be activated
- Optimization of Communication Data Amount between Client and Server
- Changing serialization format from JSON Text to MessagePack
- Format conversion must be needed both side
- Activate data compression on HTTP layer (gzip, deflate ... etc)
- Changing serialization format from JSON Text to MessagePack
- Developing More Scalable Overlay Transport
- Overlay NW with Mesh library may not scale over 100 nodes roughly according to a description at here