try this just for a check no wallet required let us know if that works for you ?
./dweb.exe open ddec1667f53d6814b07aeaf4d4ca8466a3fc10785889d9de122a4d93fb8178ca
and another one
./dweb.exe open 1fac0b4e342802a4aff9a43a7427f0ac989475d4a5a6ff566445366b344cd063
Atlas needs a wallet to create an account where you can follow people but the link i posted above is just a site template that doesnāt require a wallet for view only 
I managed to follow people on Atlas without a wallet being set up, though I may lose everything when I restart it, but at least I can see all the stuff and follow links.
The template site loaded no problem.
Iāll get a wallet set up
I wonāt be back on this until Tuesday but this is now at the top of my list!
Thanks again.
just tested atlas shout feature from windows and it looks like it is working
ā edit
beg blag plays
but billboard looks like its not working for saving updates dweb error it loads fine whats already there though
DEBUG serve with ports HttpRequest : PUT /ant-0/scratchpad-private
DEBUG serve with ports HttpResponse: 400 Bad Request (Bad Request)
videoās play from atlas as well
This is the kind of early use case that could be perfect. Game mod communities could work as well.
The value can be easily accessed by people without needing to sign up for an account / connect a wallet etc, but once they see the value, they may want to explore further, or set up an account to comment / upload their own files to share etc.
Getting a few privacy / decentralisation / crypto focused youtube channels to put their video catalogue on Autonomi could also be good (anyone could watch with no ads etc).
Itās great to be having a look at some of this today (watching videos, listening to music, playing games, reading blogs, all hosted on Autonomi)ā¦ makes me excited to see what the next weeks and months bring with further improvements in network performance, apps, and the Autonomi ecosystem & user experience in general.
Dweb, Anttp, Atlas, and all those uploading stuff to share provide a fantastic early taster of whatās to come. Pioneering stuff happening here 
MacOS binary works, even on my old Big Sur laptop, so I can actually run dweb locally.
Try setting a private key with some ant and Eth on it so you can create an account for attlas
@ambled @DavidMc0 can you guys try these links and report back if they work or not ?
no wallet or account required with these ones.
Yes, they both work no bother with no wallet 
or a diffrent way:
./dweb.exe serveIf it works you can save the 3 lines below as dweb.ps1
$env:SECRET_KEY=ā0e95452fb5a25bca51b321d53155e4a028cafb3b2a1bf6537630494f73970e17ā
cd C:\dweb
./dweb.exe serve
The secret key provided in the script is loaded at the moment for testing purposes, just put in your own if that one gets drained.
Fantastic work @happybeing !!! double the speed vs linux on windows
well done thatās fantastic two windows customers in one day
I do have a funded wallet (10ANT,$1USDinArbETH) exported to SECRET_KEY on my dweb serve session.
dweb-cli 0.8.2 dweb-darwin-amd64
Actually I got those both to load.
For Atlas, I see this in the dweb serve log
DEBUG www_handler(/)...
DEBUG our_directory_version:
port: 36678
history_address: Some(HistoryAddress { owner: PublicKey(19e3..b297) })
version: None
archive_address: 8ba45bbe852d91d638cc16923e384060add5419404b5b61bcfe39fd08636fe96
Splitting path '/'
...into '/' and ''
Looking for resource at '/'
Retrying for index file in new_resource_path '/'
DEBUG looking for a default INDEX file, one of ["index.html", "index.htm"]
DEBUG lookup_name_in_vec(index.html)
DEBUG lookup_name_in_vec(index.htm)
DEBUG: immutable data with eTag: "immutable-1213194602316699719-text/html"
DEBUG ETAG COMPARING: "immutable-1213194602316699719-text/html" and "immutable-1213194602316699719-text/html"
DEBUG serve with ports HttpResponse: 304 Not Modified (Not Modified)
DEBUG serve with ports HttpResponse: 200 OK
DEBUG serve with ports HttpResponse: 200 OK
DEBUG make_error_response_page() - message: scratchpad_private_get_owned() failed to get private Scratchpad from network - Network: GetRecord Query Error RecordNotFound
DEBUG make_error_response_page() - message: scratchpad_private_get_owned() failed to get private Scratchpad from network - Network: GetRecord Query Error RecordNotFound
DEBUG serve with ports HttpResponse: 404 Not Found (Not Found)
DEBUG serve with ports HttpResponse: 404 Not Found (Not Found)
DEBUG serve with ports HttpRequest : POST /ant-0/scratchpad-private
DEBUG serve with ports HttpResponse: 400 Bad Request (Bad Request)
^^ @Josh maybe one for you Iām not sure. Let me know if I need to look into it.
awesome Erik, thank you.
Thatās interesting, what seems faster - app/site loading I assume?
@ambled thanks for testing. Looks like the build works reasonably on Windows, Mac and Linux which is shockingly good!
I take a day off and you guys get real busy. 
This is great to see, and the progress with AntTP too. I think it would be good to begin convergence on REST APIs as we seem to be duplicating more now. Maybe at some point one can be retired, but for now I think itās good to have separate strands.
@Traktion Iām assuming your API is a more standard mapping to Autonomi. Mine is one-to-one too, pretty much but has extras built in to simplify app development (eg with named objects and per type key derivation, extra control via custom headers etc).
What we could do is put a common REST API together on the same path that is as close to Autonomi as possible, and move anything that has extras onto a separate path.
So for example, standard on /ant-0, my enhanced equivalents on /dweb-0 your on /anttp-0 and go from there. Just using those as examples, happy to adjust if youāre in.
In time we might decide to migrate some of the extras into /ant-0 in response to developers.
Developers could build on a common REST API that works with either dweb or AntTP, or for just one of them if they prefer.
What do you think?
Yes, as close to one-to-one as I could make it, really. I didnāt want AntTP to have much of an opinion on how those data types should be used, but rather a wrapper for the library APIs in REST.
There is a little creativity with the likes of stratchpads, as we basically have public/private stratchpads in reality, but not in name (in the autonomi API). From glimpsing a recent Maidsafe PR, it looked like they were moving towards formally exposing public scratchpads too at the API level, so I hope it is on the right track.
Additionally, I interpreted name in the same way for a number of endpoints for deriving the keys, which isnāt fully consistent with the libraries. From testing, the same logic applies for deriving the keys, but the examples in the docs illustrate the key generation differently.
Additionally, there are binary and multipart endpoints (where applicable), which take raw application/octet streams and multipart/form-data respectively. These complement the JSON REST endpoints, but provide support for alternative interfaces, e.g. binary POSTs donāt need to be base64 encoded and add no other body properties and multipart POSTS expect a HTML form submission, with base64 encoded parts. These can both be handy for browser integration, where JSON REST may not be ideal.
Yes, I think that would make a lot of sense. Having a sort of ācoreā set which purely echo the library and then a complimentary set to add features, seems like a good mix.
I would request that we went with the naming convention for using versioning in the URL though, if possible, e.g. REST API Versioning: How to Version a REST API? with /v1/*, /v2/*, etc. Itās not a requirement, but itās very common and should help folks understand what weāre doing.
I stuck a /api prefix on the versions, just to make it clear that it was a special URL with API calls in it (as opposed to regular files in the path). However, it would be feasibly to route either, if you felt strongly against that (or any of the above, tbh - we could both support both, etc).
Yes sounds good. If we want /anttp/vX instead of /api/vX etc, I could get behind that too. I donāt need/mean to claim /api/vX as the standard, really. I just wanted it not to mess/conflict with anything else and it seemed a decent place to start.
FWIW, the lack of opinionated API endpoints was to encourage more logic to appear in client side libraries (e.g. in typescript). I think there is a place for both approaches though, depending on the goals of the service hosting the endpoints.
Maybe, in time, we could plug modules in that support extended service features, such as more opinionated APIs, etc. Popular ones would certainly end up bubbling up to the top. It would also allow folks to adopt a licensing model they are happy with (by including/excluding modules to suit).
Yes, seems like a great idea and a good time to start pushing towards this.
Note that the v1 endpoints on AntTP are very much v1! 
Not sure myself, I have only been able to recreate with a empty wallet which ambled says was not the case. I have updated the message to say check your wallet balance but otherwise 
.
All sounds good and Iām sure Iāll learn from your APIs as they are as well. I also have a mix including multi-part, binary, JSON etc. Another area of difference may be how we return struct results - for example when doing put/get Iām using Rust structs with utoipa Schemas. I see you added swaggerUI so are you also using utoipa for docs/SwaggerUI? If so us both using the schema of common Rust structs would be a good way to go.
I donāt have strong feelings about the paths except forā¦ /v1 etc which I explain below, but first another possibility that occurs to me is for us to standardise on the base APIs (/ant /api or whatever) and to allow a header which enables extra features. That might simplify some areas of the handler code, but tbh it will just make the docs harder to explain, having optional features in many APIs all enabled by a custom header. But I mention it anyway.
Back to why I avoided /v1 etc for versioning: that was because I wanted an optional āversionā in the path of APIs which accept a History (which is quite a few) so I went from /ant/v0 to /ant-0 and can use /archive-version/[v<VERSION-NUMBER>/]<ADDRESS-OR-NAME> where ADDRESS-OR-NAME resolves to a History (similar to Register).
I use that in several my APIs (e.g. for links to another website with /dweb-open/[v<VERSION-NUMBER>/]<ADDRESS-OR-NAME><REMOTE-PATH>). The version is optional because you can leave it out, in which case you get the most recent version in the History. Iād planned to use the same convention for Registers. So I wanted to avoid having another /vN in the path. Normally Iām a slave to such conventions
I suggest we pull this into its own topic so Iāll copy my first post onto the topic below, and if you can copy your reply there, Iāll reply to that with this. If that make sense 
@ambled, can you post much longer logs because the errors shown up to that point are to be expected I think, at least if Atlas still works the way ScratchChat does - it tries to access the Scratchpads when first started, and obviously they wonāt exist if this is your first run.
I need to see if it gets to trying to create them. Please also take a look for errors in the Browser console. There will be ones equivalent to the log you posted from dweb serve but there may be be others preventing Atlas from getting to the create part.
Thanks again for trying it all and reporting the issue.