and I guess I still shouldn’t overthink stuff 
… we want to release! … and can switch out the communication technology later on without too much of a hassle if I design it right ..
I’ll temporarily add a central point of failure for friends and host a rendezvous server (behaving like autonomi does just faster; and clearing all cached data after 15 minutes or so)
→ the one creating the offer posts it to the server (like he’d do on a faster scratchpad)
→ the one reading the offer and posting the answer does it from/to the server (like he’d do on a faster scratchpad)
priority management and encryption key get exchanged via autonomi; just the innermost webRTC handshake gets outsourced.
after that:
- we can focus on adding the plugin system that is probably interesting for other projects wanting to create extendable apps on autonomi via dweb too
- enable a friends lists and multiple chats
- adding friendship requests (
I think like plugins that’s not a super obvious one 
enables forwarding of contacts/reaching out to someone without connecting somehow bidirectional before. It’s a way to enable shops and orders being sent from strangers too - (you simply specify where you expect them… And if someone wants to send it to you they can use the key you published and check regularly) - some cleaning of code
- and after we have released a extendable, themable app on autonomi (using chunks+scratchpads) we can go back to examining the communication channel and analyze how we get rid of that central point of failure again