Thank you very much to every supporter of Friends who voted for this project.
(I’ll just assume that we did make it through the voting because I don’t see why not) looking at the Timeline from here on it is rather tight (which is my fault ofc) because I won’t have time for this project from mid-june to mid-july (…and before doing the quick planning just now I somehow didn’t think about it and that the timing is horrible considering maidsafes timeline)
That’s why I’ll not invest any time into “Memories” the other project I had in mind and fully focus on Friends.
Shorter Timeline means I’ll strip down features at first to make sure there will be something online July 17th and will iterate from there to more powerful releases
V0 - initial release the minimal version of a chat app running on autonomi:
1:1 chat
entering peer info into input fields
Frontend written in Svelte
dweb by our awesome @happybeing will be my autonomi proxy of choice because it supports versioned websites (the chat-dapp) which means I can update the app without changing links for all users and at the same time if one version contains a bug users can go back to the previous version
autoprox will be stripped down to only offer a local webSocket and a version info route; full focus on hole-punching and communicating via encrypted reliable udp - no parallel development to dweb.
(hole-puncher) companion-app will be written in python and packaged via pyinstaller for windows, macOS and linux (if the dapp doesn’t see it running it should provide a link for downloading the companion-app as immutable data from autonomi)
V1:
n:n multi chat (one global autonomi chat)
peer-info loaded from scratchpads (every chat participant updates his own scratchpad)
chat-participants add their scratchpad-address to the global autonomi chat scratchpad
inactive peers will be removed from the scratchpad again by other chat participants
V2:
adding message-modifier plugins as web-components dynamically loaded as immutable data from autonomi (on bux’ request: remove-toe-gif message-modifier will be the first plugin)
side notes:
cracking into hard nat (symmetric nat)
themes / other plugins
friends as web component itself (to include it into other apps)
generic communications nodejs library on npm for other apps to use p2p signaling/live data exchange
tauri packaging
hole-punching library in rust/nodejs
mobile support
audio
video
are topics I’ll most certainly not manage to implement all in this limited time window but plan is this will follow afterwards.
We’ll see how fast we proceed on this path. I’m pretty confident we’ll need to extend this plan until we reach mid-june but you never know.
expanding a bit on the initial architecture of the app
Login / Account Management
The app will use a username+password to derive deterministically a user data scratchpad where stuff like friend lists, multi chat addresses with names, companion app info, currently imported/activated plugins,… Will be stored - all this is stuff that is modifiable by nature and doesn’t need to have a history (for friends and chats I may reconsider at some point and switch over to a graphEntry chain)
On password or login name change the previous Scratchpad should be cleared and a new user data Scratchpad created. (there could as well be just one login passphrase … but people are used to username + password and using 2 parts decreases probability of collisions greatly - when the friends login passphrase gets stored in a users vault this user/password obviously should be removed … but for starters I’ll go with this simple scheme)
companion app
The companion app will run locally, there will be a default port (range) where it should be running and the webapp can scan for it anyway… But for less guessing and easier discovery it will write the currently used port to a Scratchpad on the network so friends can just see in the user data if a companion app already was installed (on this device) and where it should be running to either prompt a install or a restart (or just connect to it)
later on the companion app can become a service with registered System-uri → if it’s not running already a click on a link ( friends://start-companion-app ) that should restart the process if it’s not running but installed on the system (like this: https://unix.stackexchange.com/questions/497146/create-a-custom-url-protocol-handler) - I will check out if passing a XOR-url (containing the friends app + a friends scratchpad ID as query argument) can be used too for easy peer-import → so that if you click on friends://profile/<yourFriendsFriendsID> this opens an the public profile of your friend where you can click on “import” - I think this should indeed be possible by firing a dweb open command and passing the arguments (the friends app then parsing the query args again).
peer discovery
Third used Scratchpad will be the ‘my public peer info’ (probably will be expanded to a full public profile page) Scratchpad where friends stores the current ip+port of the user (together with info hard or easy nat and used public key for signature verification, DM encryption etc.)
This is the Scratchpad address that needs to be shared with your peers to initiate a connection/friendship between you (I’ll call it the Friends ID - can ofc be easily encoded in a QR-Code later)
first pre-release V0-alpha may not use any of the scratchpads and is possibly just Friends hosted on Autonomi + a companion app that needs to be cloned and run from GitHub
(ofc anybody should feel free to comment and throw in ideas - I do have a plan and will probably not follow every suggested concept but always good to discuss and consider different designs)
it’s incompatible to the current hole-punching-communication-service and doesn’t even let you input text and hit sent because there is no connection xD … imho that’s an anti feature and without connection it should let you insert text and just cache it locally … I will change that …
but success of the night:
stripping out unneeded fluff that doesn’t fit to the current concept with plugins etc.
creating a app bundle with as few as possible files (autonomi optimised bundler settings - with this simple app 18 → 7 files)
uploading the app bundle to autonomi and seeing that it’s working as expected and gets served by dweb just like it should.
next steps:
stripping out all unneeded elements from autoprox and making it a pure holepuncher-service-websocket-relay companion app
then making web app and companion app compatible and working properly for 1:1 p2p communication
uploading the companion apps for macOS, Linux and Windows as immutable chunks.
making the friends frontend detect the OS of the visitor.
suggest to download the companion app if it doesn’t run on the expected port and provide a link for downloading directly via autonomi.
okay … a couple of bullet point but it’s not thaaaat much .. then we’re already at the V0 release
… family stuff … day work stuff … didn’t have much time the last days.
did optimize the udp-holepunching library a bit for my purposes, released the new version, stripped down autoprox to only offer a websocket relay (well … and some info routes … but no longer wallet management, data query etc …) and made it use the udp library as first iteration.
next step will be to change the frontend to use autoprox as companion app for own ip/port discovery via public stun servers and to see if the current implementation for frontend-websocket-udp-websocket-frontend communication works as expected (it never does on first attempt) and what changes are needed.
Once those 2 (/3) components are compatible and working together I’ll use pyinstaller to make the first version of windows/linux/macOS companion apps + upload them to the network and link them in the frontend app + test it as App delivered via Autonomi.
Since the App itself lives inside Autonomi then + utilizes Chunks to retrieve its companion App this should already be enough to count as “deployed” according to the rules of IF.
From there I’ll add a simple login scheme that allows account login and account switching + stores the peer info in a scratchpad on main-net. (and from there you won’t input your peer info as ip:port but as a scratchpad address that gets updated by your peers when they are online; I’ll probably add a timestamp too and if it was not updated within the last 15 minutes there is no point in trying to connect because the app updates the peer info in shorter intervals…)
we’re well on track
ps:
maybe to be a bit more specific about the platforms I’ll build for:
macOS Desktop (apple silicon - so the m1-m4 series - no intel based apple hardware)
Linux 64bit (x86 → Indel/AMD and arm 64bit) [so that happens to be 2 binaries …]
Windows 64bit
Edit: with the move to WebRTC friends doesn't need a companion app anymore and all platforms are supported out of the box without me building for anything specifically
…later on I’ll utilize GitHub actions or so to automatically create those releases to not having to do those 4 builds by hand on every new release … any maybe publish to autonomi directly from another pipeline … we’ll see if I’ll really go that far … but setting a private key as secret and using that from a pipeline where it has access to a few cents doesn’t look too bad to me …
actually I’m not sure @happybeing is planning to long-term maintain and improve scratchChat it’s mainly to demo scratchpad usage via dweb I think
but ofc he’s free to correct me here.
I think the basic used technology is very different; but ofc chats may use (scratchChat-like) scratchpads to store mutable snapshots of a communication channel until that reaches a certain size (12mb?) to synch chats across devices/persist through app restarts and then the history might be stored as chunks on the network and linked in a graphEntry chain to make sure you can scroll back into history right to the genesis of your conversation with someone.
since friends is unexpectedly high in the ranks I will reorder priorities to maybe enhance our chances to really appeal to the judges too
Since ingegrating with webRTC is pretty straightforward but requires https to be active I opened a pull request for https support in dweb. The implementation I suggest is already working but it will probably take some discussions forth and back until @happybeing is happy with the solution too I am sure it’s not rust programming quality at his level xD (doesn’t stop us from successful deploy - I can precompile my custom dweb version for people to test)
webRTC connection info exchange via scratchpads on Autonomi is now next on my list → successful deployment
I will implement one simple version of the plugins and publish one first plugin to autonomi to showcase how plugins developed by 3rd parties can be included in autonomi web apps (I think this is a pretty elegant way to do it and that it is possible (through the JavaScript Webcomponents dynamically loaded and referenced in a user-app-settings package)) since it is probably not obvious. After that you can Log into your account on any other pc on this planet and your plugins are being loaded automatically too
I will make the whole Friends App a Javascript Webcomponent that can be dynamically included by random devs in their apps (same systematic as the plugins)
even with the chat itself then being just a 1:1 p2p chat and multi-peer chatrooms might not be part of Friends while the IF program is running this package of:
proof of concept using autonomi to exchange contact info for a webRTC p2p chat (we’ll see if audio/video is straightforward enough to be included within the available timespan of IF … I think that’s quite possible but of 2nd priority to me)
showcasing how to develop and use plugins on autonomi web apps
making your app available for others to consume/combine with
should showcase 1. that the app concept works and it has the potential to be a “self hosted” chat app (well … without you hosting anything … but you know what I mean) - fully private and without any middlemen; only precondition is dweb being running … the functionality could be integrated in a future autonomi browser as well 2. pretty innovative and powerful concepts are being developed and given to the world to do with it whatever they want (MIT license)
which I hope will appeal to the judges and check as many boxes as possible on their criteria list
thank you very much for your continued support
here a screenshot of the first WebRTC version of Friends running locally via https - just because screenshots are nice
Why? There are still a lot of OSX users with Intel chips. Additionally, users with M-series chips can run programs written for Intel, but not vice versa.
Just want to note that I’m prioritising dweb features to support @riddim’s work (as I will for others making requests) and don’t expect this to take long.
I haven’t looked at his PRs yet (yes two!) but will integrate them ASAP. The main point of discussions will I expect be to document the reasons and any notes about these enhancements. They can be removed later after all
I’m working on a new feature and then will look at these and maybe release them all together.
That’s actually a pretty good question - let me think about it - I may write outgoing messages to the connection Scratchpad if the receiving connection is not established (like scratchchat does) and data is then being received when the communication partner comes online again.
But since multi user chats will probably heavily influence the design of my implementation for chat history and handling of broken connections etc… I will most certainly not cover this before the implementation of multi user chats and until then no chat history is kept between sessions (maybe in localstorage if my 2nd dweb pull request goes through… Because that’s easy enough to do) and no messages can be sent/received if not both parties are online (if the connection is not established you will be able to prepare and enter messages but the send button will be deactivated - same as for history - might be cached (on the current device) via localstorage soonish - later even via Scratchpad to have drafts synchronised across devices - but that’s not of highest priority for now for me)
Interesting point you raise there - but since friends moved now to WebRTC and doesn’t need a companion app anymore we’re truly multi platform now and OS / processor architecture are not relevant anymore!
Friends now supports every device capable of running a browser with Javascript and WebRTC support (which should be pretty much everything anybody wants to use - except maybe for terminal browsers… But… Well… )
I think that’s a viable solution in early phase. And it should be clearly indicated why the button is greyed out. It might even be a desirable option for later phases too - to really not have a “third point” records.
But in general I think the possibility to send written messages to their way even when the other parties are away, is so ingrained on our ways of using messages, that it is a must for any messenger app to be successful.
Absolutely - yes - and with Scratchpads as alternative (slower) communication channel when the other side is not listening absolutely possible
(the only issue then is size limitations of Scratchpads and e.g. Picture/file sharing…quickly raises ux questions… )
Yeah maybe a simple question ‘should the data be uploaded (costing fee+ANT)’ might be good enough in that case
Persisting data sent to others and linking might be cool anyway… So probably should be a possible (or default) feature for any sent picture/file I guess… I guess I’ll implement one way of doing it first and we’ll see how that feels and iterate from there to get the best ux
… before I upgrade the version already running on autonomi I’ll implement and test the WebRTC flow via Scratchpad. (+maybe will do some frontend tidying) … uploading this version that doesn’t look too nice and still requires copy+pasting OFFER and ANSWER around doesn’t look right …
ps: I especially like the blur-effect for the background when the account is not ready yet
@riddim my brother, once you launch, please provide some super easy instructions on how to run this thing. I mean, like for someone who never heard about Autonomi and is not very tech savvy and never interacted with blockchain. Even if it is not a finished product, we need as little friction as possible when trying to showcase these apps to the general population
… I will change that …
we’re truly multi platform now and OS / processor architecture are not relevant anymore!
