MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 21 Jun 2023 09:14:05 +0100
Message-ID: <CALZpt+EGfF_=0voijO3=D0fzs2+uSC5ZGf=F1HmKoDiVUw43KQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000090d5e605fe9f5ada"
Subject: [bitcoin-dev] CivKit Node v0.0.1 release - "Sic itur ad astra"
Precedence: list

--00000000000090d5e605fe9f5ada
Content-Type: text/plain; charset="UTF-8"

Hi Bitcoin Devs,

Proud to announce the first release of CivKit Node, a basic Nostr relay
with additional features to have a functional peer-to-peer market board,
written in Rust [0]. This is a very raw release as since we published the
paper back in April, we've been reached out by a bunch of folks asking how
they could contribute by code, or start to integrate CivKit in their Nostr
and Lightning peer-to-peer market clients [1].

Current release is CLI-only, just implementing basic NIP 01 support and is
full of bugs and todos, has not been tested on a lot of platforms and still
works as a local host for a lot of things [2]. There is a sample Nostr
client binary joined for deployment and testing purposes and an utility
binary to manage the node with a gRPC interface. Such an interface should
lay the groundwork to build one or more GUI applications on top, as it's a
recurring and consistent request from the community.

There is an experimental integration with BOLT8 Noise transport (thanks to
LDK), where one can connect to another CivKit Node has a peer, Idea is to
unify the communication infrastructure between Nostr and Lightning, and as
such have a single market of p2p service providers (watchtower, state
backup, boards) benefiting from network law effect. Beyond sharing all the
work between Lightning and Nostr ecosystem in terms of spamming
mitigations, careful crypto engineering (e.g onion routing) and
privacy-preserving monetary credentials [3].

With this released out, I think we'll go for sound onion routing support,
BOLT12 offers, the set of fundamental NIPs like NIP-09, NIP-16, NIP-33 and
others, and integration with a notary protocol (e.g Mainstay). Still, we
would like to listen to our users and we'll plumber features in the
function of relevant feedback collected from the community. One key lesson
from years contributing on LDK, we do not want to stay in a "purist
developer" ivory tower to avoid hard-to-integrate APIs, and make the
"product management" of the project owned by the community to ensure we're
building for the real-world of unstable and constrained mobile clients.

Once we have communication infrastructure and hopefully credentials
framework working, I think we'll start to have more serious development of
the CivKit functionaries services themselves (e.g market bulletin boards,
rank proof servers and moderation oracles in the paper parlance). Though
again, if folks want to start more custom services on top of CivKit Node,
we'll see what we can do, there is a brave new world to explore with Nostr
and Lightning maturation.

For the historical note, peer-to-peer market features were present in
Bitcoin Core circa 2010 (in fact before the ref client was dubbed Core).
Those features were removed by commit 5253d1ab "strip out unfinished
product, review and market stuff" by Satoshi [4]. Retrospectively, it was a
good insight as Core has evolved as a complex beast enough and careful
layerization is one of the best learning from the 50 years of Internet
history. Still, censorship-resistant and large-scale peer-to-peer markets
sounds still one of the missing blocks of the Bitcoin protocol stack.

Looking forward to growing the Bitcoin and Lightning internal economies by
an order of magnitude or two with the CivKit Node, if the kharma is with us.

All works are released under MIT/Apache licenses and we aim to bind to the
best open-source development standards as set by Bitcoin Core and the Linux
kernel communities and we're welcoming anyone strongly willing to build
with passion and love.

I think for the future, we'll do the announcement on its own communication
channel, whatever a new mailing list, or something experimental on top of
Nostr groups, Still, if we innove in terms of cryptography we're aiming to
have things standardized under BIPs.

"Sic itur ad astra" -
Block 000000000000000000053fd09a45f48e747f281122021edc2f7e97efcdd66248

Cheers,
Antoine

[0] https://github.com/civkit/civkit-node
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021556.html
[2] Of course, there are gazillins of things to implement, please open an
issue on the repository directly rather to yell something doesn't work.
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html
[4] https://github.com/bitcoin/bitcoin/commit/5253d1ab

--00000000000090d5e605fe9f5ada
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Bitcoin Devs,<div><br></div><div>Proud to announce the=
=C2=A0first release of CivKit Node, a basic=C2=A0Nostr relay with additiona=
l features to have a functional peer-to-peer market=C2=A0board, written in =
Rust [0]. This is a very raw release as since we published the paper back i=
n April, we&#39;ve been reached out by a bunch of folks asking how they cou=
ld contribute by code, or start to integrate CivKit in their Nostr and Ligh=
tning peer-to-peer market clients [1].</div><div><br></div><div>Current rel=
ease is CLI-only, just implementing basic NIP 01 support and is full of bug=
s and todos, has not been tested on a lot of platforms and still works as a=
 local host for a lot of things [2]. There is a sample Nostr client binary =
joined for deployment and testing purposes and an utility binary to manage =
the node with a gRPC interface. Such an interface should lay the groundwork=
 to build one or more GUI applications on top, as it&#39;s a recurring and =
consistent request from the community.</div><div><br></div><div>There is an=
 experimental integration with BOLT8 Noise transport (thanks to LDK), where=
 one can connect to another CivKit Node has a peer, Idea is to unify the co=
mmunication infrastructure between Nostr and Lightning, and as such have a =
single market of p2p service providers (watchtower, state backup, boards) b=
enefiting from network law effect. Beyond sharing all the work between Ligh=
tning and Nostr ecosystem in terms of spamming mitigations, careful crypto =
engineering=C2=A0(e.g onion routing) and privacy-preserving monetary creden=
tials [3].</div><div><br></div><div>With this released out, I think we&#39;=
ll go for sound onion routing support, BOLT12 offers, the set of fundamenta=
l NIPs like NIP-09, NIP-16, NIP-33 and others, and integration with a notar=
y protocol (e.g Mainstay). Still, we would like to listen to our users and =
we&#39;ll plumber features in the function of relevant feedback collected f=
rom the community. One key lesson from years contributing on LDK, we do not=
 want to stay in a &quot;purist developer&quot; ivory tower to avoid hard-t=
o-integrate APIs, and make the &quot;product management&quot; of the projec=
t owned by the community to ensure we&#39;re building for the real-world of=
 unstable and constrained mobile clients.</div><div><br></div><div>Once we =
have communication infrastructure and hopefully credentials framework worki=
ng, I think we&#39;ll start to have more serious development of the CivKit =
functionaries services themselves (e.g market bulletin boards, rank proof s=
ervers and moderation oracles in the paper parlance). Though again, if folk=
s want to start more custom services on top of CivKit Node, we&#39;ll see w=
hat we can do, there is a brave new world to explore with Nostr and Lightni=
ng maturation.</div><div><br></div><div>For the historical note, peer-to-pe=
er market features were present in Bitcoin Core circa 2010 (in fact before =
the ref client was dubbed Core). Those features were removed by commit 5253=
d1ab &quot;strip out unfinished product, review and market stuff&quot; by S=
atoshi [4]. Retrospectively, it was a good insight as Core has evolved as a=
 complex beast enough and careful layerization is one of the best learning =
from the 50 years of Internet history. Still, censorship-resistant and larg=
e-scale peer-to-peer markets sounds still one of the missing blocks of the =
Bitcoin protocol stack.</div><div><br></div><div>Looking forward to growing=
 the Bitcoin and Lightning internal economies by an order of magnitude or t=
wo with the CivKit Node, if the kharma is with us.</div><div><br></div><div=
>All works are released under MIT/Apache licenses and we aim to bind to the=
 best open-source development standards as set by Bitcoin Core and the Linu=
x kernel communities and we&#39;re welcoming anyone strongly willing to bui=
ld with passion and love.</div><div><br></div><div>I think for the future, =
we&#39;ll do the announcement on its own communication channel, whatever a =
new mailing list, or something experimental on top of Nostr groups, Still, =
if we innove in terms of cryptography we&#39;re aiming to have things stand=
ardized under BIPs.</div><div><br></div><div>&quot;Sic itur ad astra&quot; =
- Block=C2=A0000000000000000000053fd09a45f48e747f281122021edc2f7e97efcdd662=
48</div><div><br></div><div>Cheers,</div><div>Antoine</div><div><br></div><=
div>[0]=C2=A0<a href=3D"https://github.com/civkit/civkit-node">https://gith=
ub.com/civkit/civkit-node</a></div><div>[1]=C2=A0<a href=3D"https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2023-April/021556.html">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021556.html</a></d=
iv><div>[2] Of course, there are gazillins of things to implement, please o=
pen an issue on the repository directly rather to yell something=C2=A0doesn=
&#39;t work.</div><div>[3]=C2=A0<a href=3D"https://lists.linuxfoundation.or=
g/pipermail/lightning-dev/2023-May/003964.html">https://lists.linuxfoundati=
on.org/pipermail/lightning-dev/2023-May/003964.html</a></div><div>[4]=C2=A0=
<a href=3D"https://github.com/bitcoin/bitcoin/commit/5253d1ab">https://gith=
ub.com/bitcoin/bitcoin/commit/5253d1ab</a></div></div>

--00000000000090d5e605fe9f5ada--