diff --git a/Published---public---hidden-brews.md b/Published---public---hidden-brews.md
new file mode 100644
index 0000000..d6ccf68
--- /dev/null
+++ b/Published---public---hidden-brews.md
@@ -0,0 +1,42 @@
+This document holds information previously held by the folders document in this wiki.
+
+We might be able to do something like having a special meta-tag which basically says "Author Eyes Only". If not one of the listed authors the brew does not appear in any list, and requests return either 404, 503, or whatever. Actually, this would be useful even if folders were not a thing (currently all brews are publicly accessible, with some marked as "will appear in lists as published". This tag will work to mark the brew as "definitely don't reveal to anyone else".
+
+### Published, Public, Hidden
+
+Currently the "is-published" status is stored as `"published":true` .. it could be three possible values, meaning `published`, `whatever-false-means-now-as-default`, and `hidden-and-by-that-i-mean-share-link-fails`.
+
+That way a creator can stash GM-eyes-only docs in e.g. `/user/erics/friday-game` folder.
+
+Behind the scenes the 3 values could be `published`, `public`, and `hidden`. (Or `True`, `False`, `Null` to be backwards compatible yet maddeningly obscurantist).
+
+
+## Patreon integration?
+
+https://github.com/naturalcrit/homebrewery/issues/697#issuecomment-972366463
+
+> I also just thought about this, but something that users that monetize their content might appreciate is a Patreon integration.
+> 
+> Creators could authorize their HB account with Patreon, and when publishing brews could mark them as locked behind certain patron tiers they have.
+> 
+> Patrons would also need to authorize with Patreon, but after doing so could visit the creator's page and see all the content available to them based on their subscription tier with that creator.
+> 
+> I've worked with the Patreon API in the past and it's currently undergoing a pretty big shift, just noting this for the future if the idea seems nice.
+
+Alternatively, users could maintain a folder for each tier (possibly even a smart-folder to auto-select based on tags), and set a password on each such folder. Patrons with the password can view and access the contents. The creator can change the password monthly to restrict access from unsubbed patrons, although that sounds like a fair bit of fiddly work (but doesn't require any special coding/development).
+
+
+
+## tags
+
+When we do get around to tags, and categories of tags .. one such category I'm imagining would be for licensing .. 
+
+- `license:OGL`
+- `license:Public Domain`
+- `license:CC BY-NC 4.0`
+- `license:MIT`
+- `license:mixed`
+- `license:custom`
+etc
+
+These various tag categories would be finite and pre-coordinated in the list of categories, and in the tag values within each category. Outside of those categories would be free form custom tags, which are limited only by what characters can be used to form them (probably `[a-zA-Z0-9_-./& ]` (i.e. reserving use of special chars for possible future use, of which `:` is one character obviously already in use).