research decoupling libp2p from API

[gitaaron]

There is an unwritten standard that graphql queries normally happen over http.

If we diverge from that standard we may not benefit from potential interop with other players in the ecosystem in the future (eg/ http cacheing middleware

Decoupling the complexities of NAT traversal can help us focus on the task of getting a workable API for the Photos app (even if it means it will only work over LAN for now).

Can we possibly remove libp2p from the API and add it in later down the road? Yes if it means we are not walking through a one-way door.

So I think the question is would the API fundamentally change if we removed libp2p then added it back in later down the road.

My first thoughts are no as long as we are only providing JS (or other language) libraries/SDKs and not exposing any more details of how the data is sent over the wire.

Some more thought/research should probably be put into this before making such a drastic change.

[farhoud]

I don't know about this one. we researched for a good p2p client to build are network around it for about 3 month and we came with libp2p. and then we start developing protocols.
and also :
'There is an unwritten standard that graphql queries normally happen over http.'
is not true because apollo clinet
work with multiple protocol like websocket.

[farhoud]

but on the other hand running a node in react-native is base on hack. which is involve in running a headless webview and it may take a lot of battery.
and libp2p may not be available in android and ios in near feature.