samizdapp / rfc1 Goto Github PK

This issue is to brainstorm ideas to solve decentralised name resolution.
Since we cannot rely on customer IPs to remain constant, a method of resolving usernames into addresses is required.

The two options available currently (that I'm aware of) and their issues are:

• Unstoppable domains -- requires the client to pay gas when updating records
• A DHT -- I don't think these alone are able to validate ownership of a domain

One possible solution is to require the client to sign a DHT update request with an on-device private key. These can be validated by nodes and relayed to neighbouring nodes.
Though, this proposed solution is prone to abuse. Even if nodes check that the signer owns <=1 domain(s), attackers can just request domains by signing it with junk. Maybe a POW is required?

Good work! I especially appreciate the importance placed on incentives. The private room idea is excellent.
Reading though your RFC, some questions came to mind.

1. Although Wireguard allows for mesh networks, adding a node to a network of size N increases the number of edges by N. This is exponential and therefore how can it be scalable?

2. If I understand the RFC correctly, VPNs are used to manage friends and for NAT punch-through. But if Pleroma and PeerTube already have blocking capabilities and their respective protocols do NAT punch-through. Are VPNs strictly required?

3. The network segregation mechanism seems to lend itself more to Scuttlebutt than Pleroma. What is the reasoning for choosing Pleroma?

4. PeerTube is able to make multiple resolutions available although the Raspberry Pi 4 is only able to encode video up to 1080p30. This can be done during off-peak times but live streaming will be infeasible. What resolutions should we support?
   I think a good middle-road would be to provide a presentation mode where only pictures and audio are used. This could be useful in scientific discussions.

This issue is to brainstorm ideas to solve customer certificate generation.
We are unable to just distribute an included certificate as it can only apply to predetermined hostnames and cannot be changed. Generating them per-customer would also be an obvious security risk.

I propose that within the web UI on first run, there is a button that can generate a free Let's Encrypt certificate for that device using certbot.