feat: add client notes

This commit is contained in:
vaultec 2021-10-21 22:54:05 -07:00
parent f3803bd105
commit 5bc6ebb1b6
No known key found for this signature in database
GPG Key ID: 5D3801A306E5CB25
1 changed files with 29 additions and 0 deletions

29
client_considerations.md Normal file
View File

@ -0,0 +1,29 @@
## Client functionality
* Manage local daemon admin API through HTTTP
* Connect to remote (or local) node for encoding a videoz
The client should spawn a Libp2p daemon to communicate with the local and remote encoding nodes. The problem with this is long loading to execute a command.
Another possible issue with this approach is the daemon would have a libp2p instance then the client would have one as well.
There should only be one Libp2p instance. However, with on Libp2p instance it would be impossible to self dial the same node.
So all local operations must be done 100% through http. Not great.
Additionally, local node <---> remote node communication can be done in two ways
* CLI Client --> Background daemon (HTTP) --> remote node
* CLI Client --> *spawns libp2p instance* --> remote node
Both options either require a background daemon to be running or spawn a daemon live.
A last ditch fix to this issue would be requiring all nodes participating in encoding operators to have a public HTTP endpoint.
This is not going to fly in many instances. Maybe a hybrid of http and libp2p?
HTTP for dedicated public nodes, libp2p for easy node operation with less hassle of HTTPS/SSL setup and domains.
Why Libp2p is important:
* Peer-to-peer communication from the beginning.
* Built in encryption
* No domain neccessary
* True Device-Device communication
* 2 way stream communication
* Encoding cluters made of multiple computers possibly behind a NAT firewall.
* File transfer (bitswap) and control messages on the same layer.
* Significantly easier to manage and significantly more flexible