specs VS komodo-defi-framework

The beauty of ipfs is the transport protocols are completely modular. They do a pretty good job supporting a lot of variety a separating concerns via https://github.com/libp2p/specs

For p2p networking, I'd say things are pretty interesting and boring at the same time. (Read: https://github.com/libp2p/specs if you're interested and decide for yourself)

At the bottom is the link to the more technical specification: https://github.com/libp2p/specs/blob/master/kad-dht/README.m...

The problems you described are specific to implementations, not the protocol itself. I have read all of the QUIC specs in full (since I'm working on an implementation) and have seen nothing in any of them that mandates a centralised certificate infrastructure (caveat: I have not read the HTTP/3 spec, perhaps you point out the relevant section if its in there). Of course, the most common use case requires this, but in that respect it's no different to HTTPS.

IPFS uses QUIC as one of its supported transport protocols, and this works in the most common implementation, Kubo [1]. The spec for the QUIC transport used in IPFS [2] indicates the same certificate trust policy as for the TLS protocol [3]. The latter, in turn, relies on peer-to-peer authentication with automatically-generated self-signed certificates and the use of an additional extension.

IPFS is particularly well suited to the use case of personal websites you've mentioned, as it's specifically designed to operate without any form of centralisation.

[1] https://github.com/ipfs/kubo.

[2] https://github.com/libp2p/specs/tree/master/quic

[3] https://github.com/libp2p/specs/blob/master/tls/tls.md

Yes, there is already a Rust version (https://github.com/libp2p/rust-libp2p) that behaves well at this level but I think we can reach a higher level of performance on this point with Zig. Also, if you look at the long term roadmap of libp2p (https://github.com/libp2p/specs/blob/master/ROADMAP.md), the mobile devices and IoT integrations for example are part of the considerations.

A standalone daemon that provides libp2p circuit relay services, for both protocol versions v1 and v2.

Interestingly, that section also links to one about relay connections, which seems to be closely related to the original question: https://github.com/libp2p/specs/blob/master/relay/circuit-v2.md

Hi HN,

during December 2022, we are running a measurement campaign to investigate decentralized NAT hole punching success rates using the libp2p DCUtR protocol [0]. Ubiquitous peer-to-peer connectivity is still a big challenge. If successful, NAT Hole Punching can be a game-changer for decentralised applications and networks!

For that we are searching for participants who would run a lean client on their machines that performs hole punches with other peers and then reports back the results to our server. We explained the measurement methodology in this video [1] and the linked repository above.

Running such a client certainly has privacy implications which are documented here [2]. Most importantly, we record public IP addresses, successful NAT port mappings, and the login router page (to draw conclusions about which routers work better than others).

Optionally, you can also sign up here [3] and provide additional information about your personal network and receive a personal API key so that we can link your data to your information. Obviously, this has stronger privacy implications - but this is totally optional.

The most frictionless way to participate is to head to the releases page [4] and download a client that suits your platform and needs. No sign-up required.

[0] https://github.com/libp2p/specs/blob/master/relay/DCUtR.md

Rendezvous point: The rendezvous protocol is a lightweight mechanism for generalized peer discovery. It allows for the discovery of peers in a decentralized fashion. We operate a community rendezvous point through which swap providers can make themselves known to users, and through which users can find swap providers with whom they want to swap.(/dns4/discover.unstoppableswap.net/tcp/8888/p2p/12D3KooWA6cnqJpVnreBVnoro8midDL9Lpzmg8oJPoAGi7YYaamE)

It's not regular pubsub, it's "peer to peer pubsub". It's a pubsub, but p2p, anyone can join, subscribe, publish. The libp2p project has an implementation of this https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md

Soon. https://github.com/KomodoPlatform/atomicDEX-API/issues/927

Taker Sends >B pays the dex fee so that A will start the process by locking his coins.2) Maker Successfully Sends >A picks randomNumber: `secret_A`A creates a utxo on the Bitcoin blockchain with value: 1 BTC encumbrance: the value can be claimed by A after 20 hours or by B if he knows the secret `secret_A`3) Taker Successfully Sends After seeing the above utxo, B creates the following utxo on the KMD blockchain: value: 100 KMD encumbrance: the value can be claimed by B after 10 hours or by A if he knows the secret `secret_A`4) Maker Spends A uses the `secret_A` and claims the KMD, thereby revealing the secret5) Taker Spends B now uses the public `secret_A` to claim the BTCThe times can be adjusted based on requirements of security and "ease of use" Normally, A should have a longer locktime so that B can have sufficient time to get his coins back if A doesn't reveal the secret `secret_A`for eth, CLTV and other bitcoin specific OP\_CODES are replaced by a smart contract, whose code is here: [https://github.com/artemii235/etomic-swap](https://github.com/artemii235/etomic-swap))the cross-platform implementation of the protocol is here: [https://github.com/KomodoPlatform/atomicDEX-API/](https://github.com/KomodoPlatform/atomicDEX-API/))Its [android GUI is in beta and can be tested right now](https://play.google.com/store/apps/details?id=com.komodoplatform.atomicdex&hl=en), iOS version is in [testflight](https://testflight.apple.com/join/c2mOLEoC)You can read about the Komodo team's implementation of the protocol [here](https://developers.komodoplatform.com/basic-docs/start-here/core-technology-discussions/atomicdex.html#introducing-taker-and-maker) and instructions to use the DEX through the CLI [here](https://developers.atomicdex.io)The atomicDEX application needs access to privkeys currently, but they never leave your device. We are also planning Hardware wallet support in the 0.6.0 release. This should alleviate most concerns with privkey access.

PS I also welcome if someone creates a Flipstarter for additional funding. But I recommend setting the bounty not above 1000$ as the task should be really easy for experienced developers. PPS I can consider increasing the bounty if the task turns out to be harder than #723

https://github.com/KomodoPlatform/atomicDEX-API works with full nodes too, but GUIs use SPV because there not many people around that want to sync 200 chains.

Congrats for the job, since we have a code base in rust: https://github.com/KomodoPlatform/atomicDEX-API

Project have been funded recently, you can learn more here: https://github.com/KomodoPlatform/atomicDEX-API/issues/701

There are several solutions in the build now. One of them is an Electron Cash plugin and also a decentralized exchange AtomicDEX with SLP support that will allow you to buy/sell any SLP token. There are other centerilized exchanges with SLP support like 1bch.com and anycoin.cash but they don't seem to support USDT

There is this https://github.com/KomodoPlatform/atomicDEX-API/issues/854 for ERC20 and this https://github.com/KomodoPlatform/atomicDEX-API/issues/715 for takers.

then use https://github.com/KomodoPlatform/atomicDEX-API, it has no user agreement and is used by the GUIs