ryogrid

// Code generated by protoc-gen-go. DO NOT EDIT.
// versions:
// 	protoc-gen-go v1.32.0
// 	protoc        v3.19.1
// source: np2p_event.proto

package schema

import (
	protoreflect "google.golang.org/protobuf/reflect/protoreflect"

ryogrid

This document is about trial of current NostrP2P implementation on testing network.

When trial is succeeded, you should see something like below.

How to try

Web client

You can use Web client for see global TL without setup yourown server.
https://nostrp2p.vercel.app/index.html

ryogrid

• Concept
  • Microblogging system by all user's contribution
    • Problem NostrP2P focus on: Existing distributed SNS (Mastdon, Nostr, Bluesky, etc.) place a big works on the server operators, but there is no insentive for that
• Other points
  • A system centered on broadcasting using the gossip protocol (messaging is handled by the weaveworks/mesh library)
  • Focus on ease of implementation and simplicity over performance and data consistency
    • In the end, it may come down to wanting to save man-hours, but if you put a complicated mechanism into this kind of system, it's difficult to make it work stably
    • For the above reasons, we will not adopt structuring mechanisms such as DHT (for the time being)
  • Make the whole thing fuzzy (ex: event data loss is acceptable as long as it is a small amount)
• Compared to other decentralized SNS, it is a pure P2P architecture that is difficult to operate with decent performance, but it can be managed by making a

ryogrid

正直、精査していないので普通に穴があるかもしれない。
GitHub Repo

• コンセプト
  • 利用者皆の貢献により構成されるシステム
    • 課題感: 既存の分散SNS（Mastdon、Nostr、Bluesky、etc..）は言うて、サーバ運用者にかかる負荷が高く、その割に見返りもない
• その他のポイント
  • gossipプロトコルによるブロードキャストを軸にしたシステム（メッセージングはweaveworks/mesh ライブラリが担う）
  • パフォーマンスやデータの一貫性より実装の容易さとシンプルさに重点を置く
• 結局のところは省工数にしたいという理由に落ちるかもしれないが、この手のシステムで複雑な仕組みを入れると安定して動くようにするのが大変

ryogrid

package main

import (
	"bufio"
	"fmt"
	"log"
	"math/rand"
	"os"
	"strconv"
)

ryogrid

// Bostr config

module.exports = {
  // Server listener [Required]
  address: "127.0.0.1",
  port: "8080",

  // Clusters.
  // 0 will make bostr run clusters with available parallelism / CPU cores.
  clusters: 1,

ryogrid

// Bostr config

module.exports = {
  // Server listener [Required]
  address: "127.0.0.1",
  port: "8080",

  // Clusters.
  // 0 will make bostr run clusters with available parallelism / CPU cores.

ryogrid

Introduction

• This is article about knowledges I got with survey of LMDB a DBMS

Discraimer

• The author is not an expert on database systems, so there is a possibility that my descriptions are sloppy. Please keep this in mind. I would appreciate it if you could point out any mistakes
• Some of the content is based on speculation. I write in a way that makes it clear that these parts are based on speculation
  • (Because I couldn't go as far as checking the implementation)

Why I decided to survey about LMDB

• There is a communication protocol architecture for distributed applications called nostr

ryogrid

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class BallController : MonoBehaviour
{
    public GameObject StampPrefab;
    public GameObject ParticlePrefab;

    private Rigidbody rb;

ryogrid

■meshとpion/sctpとpion/datachannelを使ったオーバレイネットワーク構築用ライブラリ Gossip Overlayの開発
・【済】read済みのデータをバッファから取り除く
・【済】ローカルのバッファを触る時はconnオブジェクトのmutexのロックをとって行うようにする
・【済】複数のノードとやりとりしても問題ないようにする（meshライブラリのユニキャストを使う時の話）
・【済】meshのオリジナルをimportする形（修正無し）で動作に問題ないか確認する
・【済】password を nil にしなかった場合に暗号化がなされるのか、なされるならどの範囲までか、を確認
　=> 同一のpasswordを設定しているノードしか同一のネットワークには参加できない模様。中継も含めて、
　　　おそらく・・・ノード間の通信は暗号化されている
・【済】新たなデータを受信するまでreadがブロックするようにする（プロキシデーモンの形にする時に必要、と思われる）
・【作業中】ノード間ごとの通信路（conn?）を双方向通信可なチャネルとして抽象化する（コネクションの概念を導入する）