docs: posts

ann/ann-025-tuns-site-analytics.md

@@ -0,0 +1,74 @@
+---
+title: tuns.sh site analytics
+description: get usage analytics for any tuns site
+date: 2024-12-16
+tags: [ann]
+---
+
+We recently enabled the ability for automatic site usage analytics[^1] for tuns
+sites. With site usage analytics, we provide webmasters with the ability to see
+unique visitors, referers, top urls, and top 404 urls. It leverages the same
+analytics system we have for pages[^2] and prose[^3].
+
+In order to see site usage analytics for tuns sites, you must have analytics
+enabled. Enabling analytics is easy, simply log into our pico TUI:
+
+```bash
+ssh pico.sh
+# -> Settings
+# [tab] to Analytics enable/disable button
+# [enter]
+# voila!
+```
+
+Then after users have navigated to your tuns site, you can view the analytics
+from our TUI:
+
+```bash
+ssh pico.sh
+# -> Analytics
+
+# [type] in input box: `stats`
+# (analytics output)...
+
+# [type] in input box: `site erock-site.tuns.sh`
+# (analytics output)...
+```
+
+# impl
+
+I wanted to touch briefly on our implementation since it relates to another pico
+server, pipe[^4], which is our authenticated, networked `*nix` pipes service.
+
+We created a pipe topic `metric-drain` where we send all site usage analytics
+info from our services (prose, pgs, and tuns). Then we have a function that
+subscribes to the `metric-drain` and adds the info to our analytics database.
+
+There are plenty of other services that could enable us to have a distributed
+system for metrics aggregation, but pipe was surprisingly pleasant for this
+particular use case.
+
+What's really nice is our observability over the metric drain. We now have a
+single channel where we can view all metrics being sent through our
+`metric-drain`:
+
+```bash
+ssh pipe.pico.sh sub metric-drain
+```
+
+During development, it was very easy for us to test this system because we can
+just submit metrics through our topic:
+
+```bash
+echo '{"host":"pico.sh", "path":"/tuns"}' | ssh pipe.pico.sh pub metric-drain
+```
+
+That's it!
+
+[^1]: https://pico.sh/analytics
+
+[^2]: https://pgs.sh
+
+[^3]: https://prose.sh
+
+[^4]: https://pipe.pico.sh

ann/ann-026-pages-http-caching.md

@@ -0,0 +1,77 @@
+---
+title: pgs.sh http caching
+description: Your pages sites are now faster than ever
+date: 2024-12-16
+tags: [ann]
+---
+
+We recently deployed an HTTP caching[^1] layer for pages[^2], lead by Mac
+Chaffee[^3].
+
+All pages sites are now **blazing** fast -- sorry, I had to say it.
+
+With HTTP caching we need a way to automatically and manually clear the cache.
+Whenever a user updates their site we will wipe the cache for it. Further, we
+also provide a remote CLI to let users clear their cache manually:
+
+```bash
+ssh pgs.sh cache {project} --write
+```
+
+We are still working through the feature-set for HTTP caching but we think we
+landed on something that should cover our use cases for awhile.
+
+> If anyone notices their site not updating when it should, please let us know
+> so we can investigate.
+
+# impl
+
+Finding an off-the-shelf http caching service was not exactly straight-forward.
+We spent a considerable amount of time experimenting with various techniques.
+First we tried caching within our pages service, then decided that it might be
+better to put it inside our reverse proxy (caddy), and then ultimately decided
+to put it back inside of our pages service.
+
+There are only a handful of Go http caching libraries and most of them have been
+archived. It seems, that fully implementing RFC7234[^4] is non-trivial and hard
+for open-source contributors to maintain.
+
+Thankfully we found souin[^5] which we can plainly see has had a ton of work put
+into it. Kudos, darkweak, your hard work on this library was much appreciated --
+I really didn't want to implement RFC7234[^4] myself.
+
+Like everything else at pico, we are always looking for ways to dogfood our
+services. The cache clearing mechanism mentioned at the beginning of the post
+was enabled by pipe[^6], which is our authenticated, networked `*nix` pipes
+service.
+
+We created a pipe topic `cache-drain` where we send all requests to clear
+caches. Then we have a function that subscribes to the `cache-drain` and clears
+our HTTP cache.
+
+What's really nice is our observability over the cache drain. We now have a
+single channel where we can view all requests being sent through our
+`cache-drain`:
+
+```bash
+ssh pipe.pico.sh sub cache-drain
+```
+
+During development, it was very easy for us to test this system because we can
+just clear any HTTP cache through the topic:
+
+```bash
+echo 'erock-neovimcraft' | ssh pipe.pico.sh pub cache-drain
+```
+
+That's it!
+
+[^1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
+
+[^2]: https://pgs.sh
+
+[^3]: https://www.macchaffee.com/
+
+[^4]: https://datatracker.ietf.org/doc/html/rfc7234
+
+[^5]: https://github.com/darkweak/souin

status/status-011.md

@@ -0,0 +1,93 @@
+---
+title: Status-11
+date: 2024-12-16
+tags: [status]
+---
+
+Happy holidays!
+
+A lot has happened this year at pico headquarters so I wanted to give a year-end
+review.
+
+Some quick stats:
+
+- 362 pages sites
+- 100 pico+ subscriptions
+- 72 tunnel sites
+- ~50 monthly active prose posts
+- ~20 monthly active pages sites
+- ~10 monthly active tuns sites
+
+> monthly active **X** = created or updated by month
+
+Overall we are seeing usage increase across all services, which is both humbling
+and exciting for us!
+
+Antonio and I (Eric) have been having a lot of fun working on pico. Every single
+day we are touching the pico platform, trying to figure out ways to make it
+better.
+
+As we reflect on 2024, we wanted to share some of our own internal thoughts
+about the platform and where we want to take it into 2025 and beyond.
+
+We recently created a new tagline for pico:
+
+> services that empower developers using `ssh`.
+
+We think this strikes a nice balance between what we are today and where we want
+to go into the future. Our focus is squarely on individual developers and
+providing tools that make their lives easier and more enjoyable.
+
+Here's a high-level summary of what we have done in 2024:
+
+- Massive improvements to [pgs](https://pgs.sh)
+  - [redirects and rewrites](https://pico.sh/pgs#custom-redirects-and-rewrites)
+  - [proxying](https://pico.sh/pgs#proxy-to-another-service)
+  - [http caching](https://blog.pico.sh/ann-026-pages-http-caching)
+  - Removed default content-security policy so it's easier for users to publish
+    sites and have them "just work"
+- Massive improvements to [tuns](https://tuns.sh)
+  - [site usage analytics](https://blog.pico.sh/ann-025-tuns-site-analytics)
+  - [tunmgr](https://pico.sh/tuns#tunmgr)
+  - [user namespace](https://pico.sh/tuns#user-namespace)
+  - [udp tunneling](https://pico.sh/tuns#udp-tunneling)
+- Introduced [pipe](https://pipe.pico.sh)
+  - Authenticated, networked `*nix` pipes
+- Introduced [git-pr](https://pr.pico.sh)
+  - The simplest git collaboration tool
+- Moderate changes to [prose](https://prose.sh) and [pastes](https://pastes.sh)
+  - [new design](https://bower.sh)
+- Moderate changes to [rss-to-email](https://pico.sh/feeds)
+  - keep-alive timers
+  - email errors to users
+- Created a log drain for all users
+  - pico TUI -> Logs
+- Created a new UI for site usage analytics
+  - pico TUI -> Analytics
+- Shutdown lists.sh
+- Shutdown imgs.sh
+- Shutdown our experimental web UI
+
+Whew, that's a lot.
+
+Beyond making our services the best they can be and experimenting with new
+ideas, we have been actively working on `pico-global`. This would deploy VMs in
+multiple regions across the planet. Our goal here is to provide low latency
+services regardless of where users live. We are trying to do it in a way that is
+sustainable for us so we are taking our time on its development. We fully intend
+to get `pico-global` released and generally available in Q1 2025.
+
+Further, we want to build services that haven't been created before. We want to
+build something that is so unique developers **have** to use our platform. This
+is easier said than done. The market is saturated. We have to be creative. To be
+blunt, **what we have today is not good enough**. With
+[radical experimentation](https://blog.pico.sh/rfc-001-radical-experimentation)
+comes tough decisions. Not all of the services we have today will likely
+survive 2025. By the end of next year, we will likely be a radically different
+platform.
+
+Thanks for taking the time to read this post, we greatly appreciate all the
+enthusiasm users have shown us throughout 2024. We are excited to continue to
+grow into the new year.
+
+Thanks and happy holidays!