Note that some sites use URLs relative to the host route. Using http://[xorname].ant/ may be a better option.
Indeed, AntTP supports that format already, iirc. Or something similar.
I’d always advise a dedicated, autonomi only, solution where possible though. Privacy and security concerns present when in a hybrid environment. I understand it is easier for folks to integrate/browse though.
I agree, they can just pick first option in my launcher, it does exactly that. Completely avoids my scoks5 and directly sets your AntTp as http proxy.
From what I’ve read you’ve got an interesting and useful approach to getting the project noticed and I like that, and you also understand where @Traktion and I are coming from on ways to support apps and services on Autonomi.
It’s good to have these ideas explored and I look forward to seeing how what you’re building works and hopefully get the results you are aiming for. Good luck and may the conversations continue 
So yesterday was spent trying to fix an issue with Caddy where the reverse proxy was working fine for anttp on the base domain for an endpoint server. The issue was when I tried to get it working on a /anttp/ path it would break in weird ways. Spent a few hours trying different solutions but after a shower decided to go the subdomain route.
Basically ws.domain.com for websockets (used to be able to download autonomi files directly within clearnet sites. anttp.domain.com for browsing anttp, and dweb.domain.com for browsing dweb. I’m just adding dweb to the endpoint server code now and having some docker build issues to sort through, but getting close. This also leaves the base domain to be used for an actual website if the endpoint server owners needs that.
Well it is censorship resistant, but I agree the privacy aspect could be worked on, or at least analyzed for more information.
Today was spent updating anttp and dweb browsing on endpoint servers. Anttp is working fine now, but I’m having some issues with dwebs port and forwarding system. Works fine on the local client as it should, but not quite on a server (which is expected as it’s meant for localhost).
So I will create an issue on codeberg in a while and try to figure out how to get it working in the strange environment that is a server 
Right now going to dweb.domain.com/dweb-open/v/awesome does redirect to https://0.0.0.0:31720 via HTTP 303, but the server isn’t set up to know what to do with that yet. So if I could get some access within dweb to something like a public hostname, or external url flag I might be able to sort it, but I think it would still need to deal with the random ports too
The rest of today was spent getting @Southside up and running with an endpoint server.
Pretty cool that discord allows the videos to be streamed directly and watched without needing to go to the actual url: https://anttp.antsnest.site/91d16e58e9164bccd29a8fd8d25218a61d8253b51c26119791b2633ff4f6b309/autonomi/to-autonomi.mp4
you can also send a websocket request to wss://ws.antsnest.site and in the message field put: 91d16e58e9164bccd29a8fd8d25218a61d8253b51c26119791b2633ff4f6b309/autonomi/start-a-node.png
Should work on any websites, they just need to connect to the websocket and send request. You can test via postman right now, but soon directly on webpages by going through the extension which lets the user also choose local mode if they don’t wanna use endpoint servers)
should anyone else wish to spin up a server, you can follow the instructions at: GitHub - SafeMedia/safebox-server: safebox server (they are messy right now, but I will have them looking nice before the 18th)
EDIT - the videos work here too, streamed from autonomi via endpoint server 
getting a 404 when I try to go through the extension
Im forcing it to use the endpoint because I don’t have dweb serve running locally right now.
Yeah that’s fine, haven’t updated the extension yet to use the new endpoint routing paths. Soon 
have some fun while waiting: AutoBoy
I mentioned it on discord, but thought it would be good to do so here also:
What I like about the direct urls, is that if it was ever posted on forums etc, and the endpoint server is taken down, the url after the domain is still valid and can be used on other endpoint servers, or directly on the local client. I’ve clicked way too many dead links on the internet (looking at you mediafire & youtube)
btw If you want to embed a video here on the forum, you can do:
<video width="320" height="240" controls>
<source src="https://anttp.antsnest.site/91d16e58e9164bccd29a8fd8d25218a61d8253b51c26119791b2633ff4f6b309/autonomi/to-autonomi.mp4" type="video/mp4">
Your browser does not support the video tag.
</video>
Got a lot done today.
Got the search bar now being inserted on all endpoint url pages.
If in endpoint mode, the extension will find the first working url and use that.
The download button works on endpoint pages now too.
Tomorrow I will flip back to updating to the latest binaries on the local client. I also plan to make it less confusing when adding an endpoint url to the extension settings. Currently you add as: wss://ws.antsnest.site but I think it would be clearer to just add antsnest.site and let the background figure out the rest.
On the endpoint server code it’s fine as it pulls the latest anttp code when installed. Hopefully that won’t be an issue as long as anttp doesn’t introduce any bugs by accident into releases. Eventually I will just set it to a specific release when we exit beta.
Today I added connection polling to show which of the endpoint servers are connected or not.
I also changed it to base domain, so users just need to enter the base domain and the backend will take care of the rest, be that for websocket connection or normal browsing.
Today and yesterday were spent doing some last minute updates before the deadline.
Today was spent figuring out how to generate the windows, macos & linux executables for the local client via github actions.
Got them generating now on new version tags releases. Thanks @Southside for testing stuff on his machine.
So confirmed running on Ubuntu & MacOS for the local client.
Any windows user want to test to see if it runs?
Today was spent removing some old code and general testing.
Starting local client:
Shutting down local client:
The local client can kill process’s if they are already in use, useful if you have old instances of anttp that are still running 
Can’t remember what version of dweb you are on? or anttp? or even ant? 
No problem, just click the new show version button 
I plan an API to allow servers to be managed via REST.
This will help because in addition to the ‘main’ dweb server, there’s a server+port for each site opened with dweb (necessary to support multiple sites open in different tabs and still support websites built with standard tools).
Looks great @safemedia. I wish I had time to play with all these things - I haven’t even had time for dweb in over a week! 
I look forward to trying it out 
There will be plenty of time, but perhaps even more apps to try out soon enough. You might have to create a checklist
