[Sun Oct 26 05:44:06 AM EDT 2025]
  Files in /var/www/html/${site}/* (recursive directory) should go in /var/www/html/shed/${site}.  They will not be accessible on disk.  When the server is started, they will be copied from shed/ to /tmp/shed, and from there soft-linked to /var/www/html/${site}.  /tmp/shed/ must be available for nginx to read.
  A configuration file can exist in any ${site} directory from which the files will be copied.  A parameter can be set to keep it on disk, and not use the /tmp version.  Configuration files use JSON.  The name of the configuration file is configuration.json.  "directory":{ "keep files on disk":[file, file...]; };
  
  A PHP script with XMLHttpRequest can be accessed by a client of their website: if they own the website, they can access certain pages.  The passcode must be stored on the server.  It can be updated by the administrator.  When a PHP script is executed via XMLHttpRequest on the JavaScript of the browser of their site, the passcode is sent with the request.
  Snailalley.com must have a link to listento.site.  In that folder, there will be the files needed to receive a message via a PHP script.  The composer of the message must have their own website.  If you have a website you can deliver and receive requests.

  A website owner might want to have a server running on their system using Ubuntu with xubuntu-desktop.  If they had their own operating system running that, PHP scripts could be used on their own web server at the machine they use.  If Filezilla was used to upload files to their remote server, which can be rented for about $5/month, the passcode needed for their site to send and receive requests could be updated from a text file.  They would not have to have Ubuntu, running linux.  There might be some scripts available to those that do, since I'm developing for xdev.zip/ as well.

  It is possible to use Virtualbox to run Linux on Windows.  Windows also has Windows Subsystem for Linux, but I'm not sure how that works.  A command in Ubuntu (xubuntu-desktop installed), popup, causes the Microsoft Edge browser to pop up without an address bar, and it looks a lot like a program.  PHP scripts could be executed from it with the click of a button.  System scripts could be run by PHP from the web browser, and shortcuts could be made.

  A user of Localhost Home might want to have their own web browser and home page on localhost/, the server running on their system which is not connected to the internet.  The web server program on the machine they use is nginx, like it is on a remote machine server that runs the server program for hosting a website.  There is a difference between a physical server and the program used by it for serving web pages.  Localhost Home is a project that could provide a user with a website on their local machine, even though they might have one on a remote machine.


Notifications
  When using a server script from listento.site/, if the user has a localhost website the remote website could be checked for updates.  They might have received a message.  There could be some way to optimize efficiency for that, and integrate notifications into the system so that it was not required to visit the remote website.  All the user would have to do is visit the remote website, like they would on a Windows system as well.  We're used to getting notifications on a phone.
  The phone gives us a lot of convenience, and it could be used for checking the website as well.  One method of notification might involve an email being sent from the user administrator's website to an email address.  If notifications were on on the phone, an audible notification could be received.  PHP has the capability to send out emails to email addresses; an entire mail server would not need to be installed.
  When the user wants to send a message, they would have to visit the page provided in the listento.site/ package.  That package should be provided for free.  Some projects might be sold on neolamia.com, where the listento.site folder is.  listento.site exists within that website, and can be reached there with the domain name.
  A page can be visited to compose a message.  When the administrator reaches the page, they will have to upload a file to compose a message.  But, the composition area shouldn't be available to everyone.  Still, without using some form of upload... what would be the way to verify the administrator?  The PHP page must be requested with a POST parameter.
  A listento.site banner could be displayed on the website.  It would be a small banner.  When clicked on it would open a <div> that has an explanation and allows the administrator to upload a text file or PNG.  Later, a PNG containing the passcode could be used.  The explanation would be there for others.

  MySQL will not have to be used.  Messages received can go in shed/inbox.  They can be written to a file.  The composer of the message has a DNS record that verifies the domain name.  HTTPS must be used so the website can be verified.
  Parameters can be set so that messages can be controlled by the reciever.  The script could be customized!  A text result containing the status of whether or not messages are being received, and how they can be composed and delivered could be returned in the request for information for the composer, before they begin.  If there is an implementation that is not available to the composer it could be explained in the text.

  A single static IP address can have multiple websites, but currently it is not possible to verify a website within an IP address.  If a single website is used at an IP address and has HTTPS enabled, it will be possible to verify them.  My domain names are used for two servers, and I have one small one that isn't using a domain name.  There are multiple entrances to my server house.  Some rooms are doing some things, and between some rooms there are doors.