I am also taking more than 8 minutes and still loading. every now and then another asset pops in, so I’m still waiting on the initial page to load and get my key…
Ok, for some it takes several minutes after the initial page load . Useful to know.
This seems to be the network. ScratchChat first checks to see if your two Scratchpads exist and if not creates them. That’s the only reason for the delay so I’m pretty sure that is just issues between your device and the network’s own response time
It didn’t work even after half an hour of waiting. Also this game site didn’t work:
Normal downloads with CLI works normally.
I don’t know, maybe something I’ve installed or uninstalled on my Linux interferes with the process? I’ve been doing some things I don’t really understand on recent months, blindly, guided by AI or various sources in the internet.
Ahh, but it is. See the inspect subcommands with dweb --help. I see you solved the issue, but with dweb inspec-files -p <ARCHIVE-ADDRESS>. If it is a PublicArchive you will see the datamap address for each file, for a PrivateArchive it will be the datamap itself.
Cool, glad you sorted it and thanks for trying it out.
I doubt this is a problem with anything you’ve installed or that you are doing anything wrong. My guess is that your connectivity is good enough for downloads but that using Pointers or Scratchpads may not be good enough on mainnet for you.
Downloads have always been more reliable than anything mutable and they still have issues but I’ve never seen them working well enough to use before.
Maybe try again from time to time and let me know how you get on.
OK, when I try again, what does it actually mean? Do I need to re-do the dweb serve too, or only the dweb open 40ea2e530a60645363ae561c8a50c165f79d8a034c4458f68f1b848c11386e45? Is it better if I close the browser tab first, or does it matter at all?
If you restart dweb (for example restarting with the SECRET_KEY properly set), you need to start with dweb open 40ea2e530a60645363ae561c8a50c165f79d8a034c4458f68f1b848c11386e45 so it sets up the port properly for your browser.
You’ll get a new port number each time you restart in this way.
My dweb that is still running continues to serve on the port that it setup and I can just reconnect my browser to that endpoint and wait till everything loads.
You need to sort your wallet out and in a terminal with the correct SECRET_KEY value, you then run dweb serve because it is dweb serve that needs the correct wallet info.
Looking at your screen shot it has reached the point of trying to pay for and create the Scratchpads on the network. So if the wallet isn’t able to pay it will retry forever. You’ll see TRY 23 … TRY 24 etc in the dweb serve terminal amongst everything else.
So I think you just need to sort your wallet and restart dweb serve and then do dweb open xxx again.
Minor update to dweb but a big leap for Autonomi as uploads are working well for me now (although Pointers may not be updating properly - things are slow to load sites due to this).
This means you can now use dweb open to open quite a few sites and hopefully more folk will publish too.
Some sites are built into this release including @riddim’s Friends app and our old friend awesome which has a list of other sites.
To install or update:
cargo install dweb-cli --locked
Start the dweb server:
dweb serve
In another terminal see the list of named sites:
dweb list-names
Try opening one:
dweb open awesome
The first load of any site takes about a minute but once loaded things will be a bit snappier. Join the fun!
Just published this update improves the performance of apps using the dweb REST APIs such as ScratchChat and Friends which you can open directly once you have the dweb server running (see dweb list-names).
The above is achieved by enabling the browser cache when accessing immutable data, including versioned data when the request specifies the version. Where this is appropriate, responses to REST requests for data etc now include a suitable ETag which allows the browser to use cached responses instead of waiting for data to come back from Autonomi.
It hasn’t changed so either local or mainnet issues. I have opened it using ‘dweb open scratchchat’ every day recently, including yesterday without issues. I’ll try again in a while and update this reply…
EDIT: unless due to a server update? Did you update and restart the server?
UPDATE: @ambled I’m running latest build of dweb and had reloaded ScratchChat with dweb open scratchchat so I think your issue is with use of mainnet somehow.
I’ve extended use of the browser cache to dweb websites and the impact is stunning. The first load will be at ‘normal’ speed but navigating around a site quickly becomes instant - and will remains so on subsequent visits until the site is no longer in the browser cache.
Next…
Thanks to @riddim I’m probably going to be able to work around the Pointers update issue (tl;dr: seems to be a problem with pointer_put() so I will try using pointer_update()). Then everything should be working pretty well with mainnet.
versioned websites load in a few seconds instead of taking ~2 minutes
dweb heal-history <SITENAME> will update the pointer for your History which unleashes this speed increase. It will for the time being also do this automatically if you just update your website with dweb publish-update ...
Add to this browser caching for all immutable data in both websites and REST API, and things are starting to fly!
The Versioned Web is Here
Websites published with dweb are not just online forever, but every version remains accessible forever. This is major plus over the web and unique to Autonomi among all the other decentralised platforms.
This applies to regular websites and web apps that access Autonomi using the dweb REST API.
This is all great news for me - all features of Autonomi data seem to be working including over mobile broadband (most things at least).
Update dweb
To install or update:
cargo install dweb-cli --locked
Start the dweb server:
dweb serve
In another terminal see the list of named sites:
dweb list-names
Try opening one:
dweb open awesome
That website contains links to several other websites including some you may not know. It has been healed’ so will load in a few seconds whereas other sites may take a minute or two until their owners have updated them again or using the ‘heal-history’ command.
Heal Your Website
Using the NAME you used with dweb publish-new you can update the pointer at no cost with this command, and it will load in a few seconds for everyone:
dweb heal-history <NAME>
NOTE: some including myself are having a problem updating or healing existing sites so if you try this, please report the success or failure here, and if you know when you created or last updated your website on mainnet, please include that in the report.