soooooo - this night I’m running a bit low on energy … so I decided to not go for the exciting webrtc handshake via scratchpad but instead go for the first (pretty simple) plugin!
external THEMES!
Pretty simple and straightforward just a css file uploaded to autonomi and as a theme you can insert the datamap address of the css file
ps: I’ll upgrade the network version of friends soonish too (right now I’m having pointer getting issues - not sure where the issue is precisely but will try again tomorrow or so ..)
pps: example css files are in the static folder - when hosted locally the link can just be entered as full path (e.g. http://localhost:8000/darkmode.css for easy testing)
in a later version of friends I’ll make sure to simplify the needed css to style friends and will add a description in the docs … this right now is just to show styling works via external CSS loaded from datamaps (and how) and is in not yet optimized for user-friendliness
next tasks will be:
WebRTC handshake via autonomi
a plugin for additional functionality - I’ve chosen here a simple but powerful one as first supported plugin
– discord-like timezone-unambiguous timestamps
– for the message-input-field a ‘add-timestamp’ button where you can select the time (and timezone if you want)
– as message-modifier → converting those <unixtimestamp:format> identifiers into readable text that updates continuously
so all in all we’re progressing rapidly and according to plan
currently utilized datatypes of the friends app on/from main net (even when the app is running locally in dev mode):
I’m pondering about email equivalent on Autonomi. Is Friends possibly close to that?
I’m thinking that maybe the basic back and forth backend is quite similar, no matter what the messenger frontend is? With a couple tweaks Friends could also have more of an email kind of UI?
hmm - to be honest friends really is aiming at instant communication and not persistence of data by default. Persisting might come later as option to turn on but will never be the focus of this.
For a Mail System I personally would choose a very different architecture; I’d need to think some more moments about it but I’d probably choose something like a simple derivation chain (or a DAG … but simple derivation might be good enough).
We’d have one root where it all starts. Most naive implementation I’d come up right now would be:
a root scratchpad (publicly readable). that’s the “address” where people will want to send their auto-mail
→ containing:
a RSA public key (you have the private key to decrypt mail sent to you encrypted with the public key
a “starting point” (publicly shared private key for a graphEntry where someone sending you a mail should put a graphEntry with pointer to a data map containing the encrypted mail to you)
optional a derivation rule for the next graphEntry (/mail) after that one. Since Maidsafe has a native derive function in their rust library it might not even be needed.
you could as well have a invite-only mail-address where you just share the entry-point with people you invite … or per person => one entry point per contact …
I think for a mailing system I would rather follow along those lines of thinking than trying to make friends a mail service tbh. Friends could indicate the status of your contacts in your mail-app
I shared this with Traktion and thought you might find it helpful. While not quite for non-techies, it goes a long way helping people understand what is happening in a codebase.
Here is the Friends tutorial.
You can select which files you want to include up to 3.5mb if using the site and more if you download it and run it yourself.
I was super excited about the change to WebRTC and the possibilities coming with it. But last night I was about to implement the Handshake via Scratchpads … and ran into timeout-issues because when writing the OFFER/ANSWER to a scratchpad it takes a while (I saw multiple successful reads with old state before the new state with OFFER/ANSWER came through) … the WebRTC flow is not made for a communication channel where the 2 messages (OFFER and ANWER) take longer than ~30s to be communicated …
…we’re at up to 2 min per direction from what I saw here … but ofc my crappy home internet and I would expect the speed of autonomi to increase with enhancements being implemented …
Right now I’m doing a bit more digging to investigate which step is allowed to take how long and how I can maybe extend some phases of the process a bit with tricks … but it’s very standardized and I’m afraid there might be a pretty hard maximum time limit for the WebRTC flow.
Since I’m working locally via WiFi and not the best Internet I’ll have a look at speeds when I host dweb on a server.
independently of the outcome of this little research we have a number of possible paths forward…
if we’re really lucky I’ll just optimize the timing of the executed operations and it works for everyone
possibly that will not work then we might be in a situation where it works for people with good internet (now) while it doesn’t work for the at least other 50%
as a temporary workaround I may use the communication scratchpad just for coordinating who creates the offer and who answers + communicating handshake IDs to use a simple server run by me for the handshake.
midterm we might be back at the companion app solution … because if we don’t use the browsers WebRTC functionality we aren’t limited by it’s timeouts …
… if someone happens to know how to expand the Handshake-Process for a WebRTC handshake for using a data channel that might take 2 minutes per communication direction please feel free to mention it here
I really like the WebRTC approach and I would like to believe that autonomi performance increase should make it all work soonish … but if it doesn’t this communication most certainly shouldn’t rely an a server run by me … so I think the companion app looks more likely again midterm than I expected/hoped …
I’ll report back when I know more about this issue / have a clear plan in this matter.
and yes - the details sometimes are just a bit … annoying … large content needs to get split up into small chunks and put together at the other side again because of size limits in the communication channel … themes do use tricks to enable background images that are being loaded from autonomi datamaps
friends reads the background image data map from the css file, creates a url correct for your dweb server (https yes or no, which port, which ip, …) and stuffs it back in through the background-url
oh - I expect these investigations now (to learn the precise limits of WebRTC, checking out if I can somehow bend the rules and make it work, where limitations are and which direction to take from here …) to take roughly one week … it’s a very important technical aspect and I want to be sure I’m not wasting a lot of time later on … +I think the solution I’ll settle for must work for more or less everyone …
Ps:
On the bright side: Did I mention that I do have pretty cool plans? xD
… For more intuitive use and less hassle even for technical people I am thinking about using tauri to make a stand alone version of friends that then can easily be installed. With tauri being written in and being extendable by rust I then can bundle the dweb functionality I’m using in friends as well as a possibly needed companion app again.
But first things first - now we need to resolve that WebRTC situation
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
I’m aiming for successful WebRTC handshake and upload of WebApp (official release on mainnet! - but working only with my modified version of dweb) within the next 24h
with this some smart-ish coordinating of updates around defined points in time (the one creating the offer at the full minute, the one creating the offer polling shortly after, and putting immediately when the new data is there, … and pushing hard and polling as fast as somehow reasonable …) roundtrip times below 30s seem very possible even on average, non-special internet (and via wifi)
… it will probably not work on every attempt … but it should work after a few from what I see if coordinated well and when the connection is established it can just stay open “forever”
I’ll see if I manage to get this working without my external server immediately after we are officially launched
i need to get some rest and a fresh mind - somehow my WebRTC connection doesn’t want to work even when i go back to the earliest versions oO I’m doing something wrong - not sure what precisely yet - no release tonight
okay … somehow I broke my mDNS resolution for local discovery of different machines behind the same router after I reactivated my pyhole again not long ago … which in turn broke everything it seems -.-" .. funnily it would probably have worked across the globe …
aaaaaaaaaaaand … I just discovered that my first diagnosis was wrong and even without https secure context is given for localhost-connections as exceptions in browsers!!! so now I guess I just need to fix my mDNS resolution (atm I modify offer/answer and replace the mDNS name with my ip …) to be able to test properly and without workaround … and then we’re good to go again!
just a css file uploaded to autonomi and as a theme you can insert the datamap address of the css file 
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)
