diff --git a/devdocs/solutions.txt b/devdocs/solutions.txt
index 6bf5c222..2d22ceb8 100644
--- a/devdocs/solutions.txt
+++ b/devdocs/solutions.txt
@@ -263,4 +263,13 @@ America/Los_Angeles
 	that's it, run it with: 
 	C:\data\code\postgres_14\bin\pg_ctl -D ^"C^:^\data^\code^\postgres^_14^\ayanova^" -l logfile start
 
-    Note: for test win64 build just copy the empty db files generated above (before any access is done) into the C:\data\code\raven\dist\win-x64\data\database folder
\ No newline at end of file
+    Note: for test win64 build just copy the empty db files generated above (before any access is done) into the C:\data\code\raven\dist\win-x64\data\database folder
+
+
+## How fast is ayanova across the internet
+TEST: TEST digitalocean, set up a server in every data center far away from here, test ayanvoa on each one and see how peformant it is perceptually, i.e. does it even matter which server we're locating people on??
+Bangalore - seems almost undetectably the same as sanfran
+	todo: test entering data on a work order, open an existing, create etc
+Singapor - excellent speed no appreciable different
+Frankfurt - excellent speed as well
+RESULT: I'd say for AyaNova there is no appreciable different from one data center to the next, the delay just isn't enough to really factor for biz software and it's super efficent in traffic which helps (back pat to me for thinking efficiently in advance)
diff --git a/devdocs/todo.txt b/devdocs/todo.txt
index c83ede03..c691a5af 100644
--- a/devdocs/todo.txt
+++ b/devdocs/todo.txt
@@ -1,15 +1,21 @@
 # now
 
 
-TEST: TEST digitalocean, set up a server in every data center far away from here, test ayanvoa on each one and see how peformant it is perceptually, i.e. does it even matter which server we're locating people on??
-Bangalore - seems almost undetectably the same as sanfran
-	todo: test entering data on a work order, open an existing, create etc
-Singapor - TODO
-Frankfurt - TODO
 
 RESEARCH: sendgrid / email system can we have a domain just for our notifications for those that don't use their own domain and use for all users (but NOT tied to AyaNova.com)
+https://linuxhandbook.com/set-up-discourse-digital-ocean/ has an example of discourse with Mailgun freen email ssytem and a domain
+
 TEST: cheapest storage for attachments possible, test out creating a new droplet with block storage to hold the attachment files to see if it's possible, how it's done and mapped etc
 
+RESEARCH: how to enable a portion of a domain from an outside to point to their droplet, is that on them or on us?
+	how does discourse do it?? https://meta.discourse.org/t/configure-your-domain-name-for-hosted-discourse/21827
+	SO, I would say it works just like we do with the test servers, they would need to edit their domain record to point a subdomain to us so we would tell them to do that, i.e. they would say
+	aya.fouralarm.ca points to [ipaddressofdroplet] or discourse does it by subdomain, they would say point to fouralarm.hosted-by-discourse.com so I wonder if we can do that too, 
+	Maybe a way to test this out is like this:
+		make a droplet, make a domain record testhosted.helloayanova.com that points to that droplet then go to ayanova domain and make a record tsub.ayanova.com and point it to testhosted.helloayanova.com
+		then make a cert on the droplet and in nginx configured for subdomain testhosted.ayanova.com and see if it works, if so then this is the pattern for customers where tsub.ayanova.com would be their ayanova subdomain
+		record they make with their domain regisrar or whoever.
+
 todo: metrics are fucked up for some reason
 	in fact I'd just like to reliably know how much disk space is in use etc, like the size of the db versus attachments in simple text
 
@@ -77,6 +83,7 @@ todo: if SAAS needs to do some things differently:
 	EMAIL - research how to send emails with a reliable provider i.e. sendgrid or alike and what the costs and add-on price for that would be.
 	SERVER / CLIENT - BACKUP we can't have them frigging around with it and fucking it up, if we're in charge we need to set the routine and locations etc, if they are in charge need to ensure it's not making too many backups somehow 
 		BACKUP screen should show capacity available in destination backup location
+	
 
 todo: each droplet for SAAS would need it's own ssh key and password to avoid eggs in one basket security scenario
 	also would need to securely store the passwords somewhere really really fucking secure like offline in a special keypass only accessible from certain hardware maybe with a digital key or something I dont' know