Just a note on the reason for this: ensuring websites and web apps built with existing web tooling work as is. I have another solution to that which doesn’t use multiple ports, but which requires a local DNS and moved away from that to simplify the user experience. So a port per site is the best way I could find of simplifying both developer and user experience, and ensuring maximum accessibility for both (including using a standard web browser with no extras or configuration).
Regarding re-use, when I switched from awe to dweb I always envisaged supporting both web (static and dynamic) and native using the dweb Rust lib. The latter has remained quite limited due to my not wanting to put the REST services in there and us end up with a plethora of local servers. I’m not sure if that is best, but that’s why much more is in dweb-cli than dweb lib. This could of course be changed.
I’m open to suggestions on how to proceed for the benefit of all, and working with @riddim has been wonderful, so if all these projects can find synergies and evolve into something that co-ordinates or converges to the benefit of more developers and users I’ll be delighted.
Right now my focus has shifted onto life things (all positive stuff) and this should continue. Over the next few years I won’t have as much time for Autonomi stuff, at times none at all. It is hard to predict though and the project remains very important to me but a more collaborative approach that builds on these foundations could be a good option. Another might be for someone else to pick this up, or for a merging of projects before it all gets forgotten.
My goal remains to get S. A. F. E. apps onto as many people’s devices as possible as quickly as possible - so cross platform, zero friction made web my priority - and making this versioned and perpetual while not needing special tooling.
Anything continuing those priorities, whether based on dweb or not will have my support and whatever practical effort I can find the time for.