I would appear to have made an arse of this. Why am I not connected?
Is dweb open a447871043968be2be1628584026cad30b824009a30eab43db3ee6dd8c0990051c27160cc8d1662da763d57c41c091f6 still the right way to start this?
3 Likes
Go via dweb open awesome to be sure.
2 Likes
hmmmmm - the tab needs to be in the foreground for a kind of reliable connection
which browser(s) are you using? - I had the impression it works better with chrome than with firefox 
1 Like
Im on the latest Brave from Ubuntu
1 Like
Clicking Friends from the awesome page gives me this
I killed any running dweb serve, restarted and this is the last output from dweb serve
port: 33999
history_address: Some(HistoryAddress { owner: PublicKey(0c3a..0448) })
version: None
archive_address: eb16e646d509f48b85797e0666ab10fda0cb19e8b5b82cc216fffa486eadc87f
Splitting path '/favicon.png'
...into '/' and 'favicon.png'
Looking for resource at '/'
DEBUG Tree looking up 'favicon.png'
DEBUG lookup_name_in_vec(favicon.png)
DEBUG: immutable data with eTag: "immutable-8298490553911241693-image/png"
DEBUG ETAG COMPARING: "immutable-8298490553911241693-image/png" and "immutable-8298490553911241693-image/png"
DEBUG serve with ports HttpResponse: 304 Not Modified (Not Modified)
DEBUG serve with ports HttpRequest : GET /_app/immutable/nodes/1.B-rdie4U.js
DEBUG www_handler(/_app/immutable/nodes/1.B-rdie4U.js)...
DEBUG our_directory_version:
port: 33999
history_address: Some(HistoryAddress { owner: PublicKey(0c3a..0448) })
version: None
archive_address: eb16e646d509f48b85797e0666ab10fda0cb19e8b5b82cc216fffa486eadc87f
Splitting path '/_app/immutable/nodes/1.B-rdie4U.js'
...into '/_app/immutable/nodes/' and '1.B-rdie4U.js'
Looking for resource at '/_app/immutable/nodes/'
DEBUG Tree looking up '1.B-rdie4U.js'
DEBUG lookup_name_in_vec(1.B-rdie4U.js)
DEBUG: immutable data with eTag: "immutable-3313927504648492931-text/javascript"
DEBUG ETAG COMPARING: "immutable-3313927504648492931-text/javascript" and "immutable-3313927504648492931-text/javascript"
DEBUG serve with ports HttpResponse: 304 Not Modified (Not Modified)
DEBUG serve with ports HttpRequest : GET /favicon.png
DEBUG www_handler(/favicon.png)...
DEBUG our_directory_version:
port: 33999
history_address: Some(HistoryAddress { owner: PublicKey(0c3a..0448) })
version: None
archive_address: eb16e646d509f48b85797e0666ab10fda0cb19e8b5b82cc216fffa486eadc87f
Splitting path '/favicon.png'
...into '/' and 'favicon.png'
Looking for resource at '/'
DEBUG Tree looking up 'favicon.png'
DEBUG lookup_name_in_vec(favicon.png)
DEBUG: immutable data with eTag: "immutable-8298490553911241693-image/png"
DEBUG ETAG COMPARING: "immutable-8298490553911241693-image/png" and "immutable-8298490553911241693-image/png"
DEBUG serve with ports HttpResponse: 304 Not Modified (Not Modified)
1 Like
that is strange - Iām getting to the friends app on port 37968
broken link is strange - I restarted everything to make sure nothing is cached ā¦ but you end up at the wrong place .. and that nobody is able to connect is disturbing too ā¦
Iāll see if I find out something later ā¦ I may be uploading a bit in parallel too and my internet connection is probably at its limit 
- that possibly doesnāt help
3 Likes
Check the address in the awesome page link.
I suggested that because I updated it a day or two ago and thought it was up to date but maybe I messed up. 
2 Likes
Inspecting the source of the Awesome page, the link is given as
Putting that into the address bar I get
Aha!!
If I wait a few mins , I AM connectedā¦
but only to riddim
1 Like
Iām not an āonlyā ā¦ 
2 Likes
I only ask you donāt be lonelyā¦
1 Like
are you ignoring me or did the connection break again?
ā¦I just learned today that progressive web apps that can be installed from a website may support executing tasks at set points in time ā¦ (thatās llm info ā¦ I need to test this to be sure ā¦)
ā¦that might be the best path to reliable handshake from my current knowledgeā¦ I need to do some tests ā¦
ā¦and Iāll split the handshake-stuff to use one scratchpad per friend ā¦ I suspect there may be stuff going wrong when friends tries to create multiple ANSERWS to multiple friends and possibly overwrites stuff in the handshake-scratchpad ā¦ ooooh ā¦ and maybe when issuing offers at first ā¦ and then answers ā¦ might be working coming from a wrong state when writing the answers -.-" ā¦
1 scratchpad per friend it is ā¦ too much that can go wrong otherwise ā¦
ps: and I suspect itās worse the more friends you have -.-" ā¦
4 Likes
No, not ignoring you at all. I was working outside while its still light.
The connection did break though at some point in the last couple of hours
1 Like
okay - in the light of latest bugs and unreliabilities I decided to invest some moments into the current release ā¦
enhancements:
-
session transfer
-
1 scratchpad per friend
ā this totally makes setting up a friend more complicated for now ā¦ but I think itās probably worth it for enhanced reliability ā¦ weāll see what the feedback from here sais how well it works after that fix
ā¦ā later weāll send invites which will lead to automatic handshake execution ā¦ so this clumsy handshake with needing to exchange contact IDs per person will go away again
-
added version info of the account package to it to be able to migrate to the new version (and removing the incompatible friends)
edit:
oh no - this is not my best release - if it doesnāt work for you then it probably isnāt you itās me :-/ let me test properly through 2 or 3 different internet connections and post again when I have something that I am confident again that it should work for others too ā¦
8 Likes
Sorry people - I didnāt forget you - Iām currently testing out different ways of doing proper tests before future releases (not only within my local network but as well between different Internet connections) ā¦ Which turned out to be more of a challenge than I expectedā¦
I Rarely use servers with graphical interface but for testing a gui app that does p2p between different locations itās pretty usefulā¦ Paperspace completely changed what they are offering (their software worked excellent in the past) with the new provider I tested clipboard doesnāt workā¦ Which is super annoyingā¦ And now I think Iāve settled at using browsh as terminal browser for my typical servers without gui (browsh supports Javascriptā¦ Without which the typical autonomi apps donāt workā¦ )
7 Likes
little status update.
first version of friends operational using individual scratchpads per friend and utilizing the auto-reconnecting smokesigns library under the hood (in this second still handshake-server to not change too much at a time)
Iāll need some more days to get to the next release. but on the bright side this one should then be significantly more robust than the last ones 
ps:
oh and more exciting stuff happened under the hood:
- i have one cloud machine with graphical user interface now to test with a proper browser
- another one where I can use browsh as terminal browser to test the behavior there
- in smokesigns I added an end-to-end test where it launches via puppeteer 2 browser windows (either headless or really to see them), establishes a real connection via WebRTC and sends messages back and forth.
- this is the systematic how I envision testing multi-user chats with >100 participants at some point through digital ocean droplets.
pps:
the only thing Iām not sure about is if I should add the invite system before the next release or not ā¦ because exchanging the individual scratchpad-addresses per friend is super clumsy and a horrible user experience ā¦ I really tend to delay the next release another week or so and having invites in place ā¦
9 Likes
I wouldnāt stress on the invite system the first customers will be the regulars who can manage just fine the way it is
4 Likes
little facelift and internal testing results.
ā¦vpn can cause trouble (possibly symmetric NAT then ..? traffic filtering happening ā¦) ā¦
- Iāll fix a bug in state management (disconnections are not correctly discovered anymore in this moment)
- and then make adding of friends a bit less confusing with the current communication scheme ā¦
and then Iāll call it the next and significantly better release ā¦ =)
Ps: oh and thank you @aatonnomicc for your patient and repeated testing of different stuff! You deserve a medal my friend
pps:
and @aatonnomicc even tested windows 
- since he was previously on mint (well and my other machines are Linux) and Iām on macOS weāve all 3 now
9 Likes
Btw - since I already see scenarios where webrtc doesnāt manage to hole punch without changing settings in firewalls/vpn I think having a optional companion app may be something worth considering ā¦
With the companion process probably being able to crack into symmetric Nat and through firewalls it could enable connections in scenarios where webrtc fails ā¦ When not being bound to the webrtc protocol/handshake style we can achieve better connectivity (+without the timeouts being imposed by browsers etcā¦) and since connections are on a 1:1 basis we can connect via webrtc to webrtc only friends and use the more sophisticated/more suitable for autonomi systematic in native app scenarios (mobile, tauri Windows/MacOS/Linux apps / webapp with companion processā¦ ).
ā¦Just some thoughtsā¦ I need to think further about this and we need to see how reliable pure webrtc turns out to be for real world application users ā¦
7 Likes
okay - you asked for it @aatonnomicc
new release with friend specific scratchpads:
Iāve got a bunch of peer-ids now for you 
b27398e82ef33ead8fc0dafa8c09850d21f0396ee08bedfbc34090febf0afb43b537848e8e698394ca9e52da69ccb378 (that shouldnāt have changed - we should be connected - just listing you here for completeness)
b34461276a8b31ac265f68e859d4ca0298781c78f8793c04db293e396a3222bca661b1807e095a67fe7f5cc51809c2da
80750630453172644ca8637ccbf7fc14938cf6f9b41b8aec05db1a3e30c2d9fd6e1e4a4c5d4673535cbb5f64d122f60f
@Josh:
a65d4caef6ff439473632257b291e3a6f517ef200cdcec1a50008bd8963bcf6ccd7970eff251b425b2307401c1034af1
969c8c2a8c52110dccceb7a6bf066e12c10e44548c42237bc74f2a0a48a0c137dce96544e79d48b67ad40016acb4677d
b6ca7ac7780dbffa1e089dd60afba0d15ac74bfa7dfa13f21a4e8efd8a66a2a8a546d844ecb51bd664e5119060c570d4
b792ed1f28106554c9f3f8de1b5172677780ca9e4acbae40f4c0c0d68d34cf2d23701a39b04e01273502f671eeaa253e
(please donāt feel excluded if I didnāt list you - just poke me and send me your peer id I most certainly forgot some important people here ā¦ )
Iām pretty confident this release is a good one ā¦ did significant testing in my local network and some testing with cloud/ @aatonnomicc
known limitations/issues:
ufw is an issue it does hinder WebRTC handshakes to be executed ā¦somehow with my new variant of tunneling firefox through the ssh session ufw no longer seems to be an issue I have to admit I donāt understand exactly why ā¦ I assume that browsh somehow was simply too slow to execute the handshakeā¦ but as long as it works for proper use cases Iām okay with it ā¦- only 1:1 communication
- since I want to avoid TURN servers weāll find out which connections go through without them and which ones wonāt ā¦ no ufw allowed is already a pretty big bummer imho ā¦ we need that other hole-puncher I was working on initially Iām afraid to get more robust here (without TURN servers ā¦ which are relay-servers for all messages so weād revert back to centralized infrastructure if weād add them ā¦)
little fun fact:
I think I either need to change the way Iām testing server-based connections or I need to optimize friends a bit for terminal browser usage - this is how it looks in browsh on cloud-machine side:
and here the version in my regular browser on my local machine
7 Likes
