Signed-off-by: Amolith <amolith@secluded.site>
---
 deploy/tel_inventory.sql | 18 ++++++++++++++++++
 revert/tel_inventory.sql |  7 +++++++
 sqitch.plan              |  2 ++
 verify/tel_inventory.sql | 15 +++++++++++++++
 4 files changed, 42 insertions(+)
 create mode 100644 deploy/tel_inventory.sql
 create mode 100644 revert/tel_inventory.sql
 create mode 100644 verify/tel_inventory.sql

diff --git a/deploy/tel_inventory.sql b/deploy/tel_inventory.sql
new file mode 100644
index 0000000..76fc583
[message trimmed]

Signed-off-by: Amolith <amolith@secluded.site>
---

The tel column is now a PRIMARY KEY so NOT NULL is no longer necessary there as
primary keys are NOT NULL by default. I added indexes for locality, region, and
available_after and removed the WHERE clause from the verify script.

 deploy/tel_inventory.sql | 17 +++++++++++++++++
 revert/tel_inventory.sql |  7 +++++++
 sqitch.plan              |  2 ++
 verify/tel_inventory.sql | 15 +++++++++++++++
 4 files changed, 41 insertions(+)
 create mode 100644 deploy/tel_inventory.sql
 create mode 100644 revert/tel_inventory.sql
[message trimmed]

>>+WHERE FALSE;
>
> why where false?

I was referencing other verify schemas and the couple I looked at
included WHERE FALSE, but I realise that's not helpful in this
situation. I can just remove the WHERE clause in v2.

Signed-off-by: Amolith <amolith@secluded.site>
---
 deploy/tel_inventory.sql | 17 +++++++++++++++++
 revert/tel_inventory.sql |  7 +++++++
 sqitch.plan              |  2 ++
 verify/tel_inventory.sql | 16 ++++++++++++++++
 4 files changed, 42 insertions(+)
 create mode 100644 deploy/tel_inventory.sql
 create mode 100644 revert/tel_inventory.sql
 create mode 100644 verify/tel_inventory.sql

diff --git a/deploy/tel_inventory.sql b/deploy/tel_inventory.sql
new file mode 100644
index 0000000..4a4e5a0
[message trimmed]

> Hi, I created a channel[0] a while back and was planning to publish a
> few short, educational videos on Emacs.  Would you be so kind and grant
> my account the upload feature.  I would appreciate it very much :)

For the time being, I'm unfortunately going to have to say no; I am
actively maintaining the system when I can, but I periodically lose
access because the server is physically managed by my co-admin and he
periodically just disappears with no warning for months at a time. I
don't want anyone to begin relying on LibreMedia only for everything to
permanently break for the next six months because my co-admin disappears
permanently.

Hello o/

I've been messing with Mycorrhiza a bit over the last couple of days and
like it a lot! :)

One feature I'm missing, though, is an equivalent to MediaWiki's
Special:WantedPages page: https://en.wikipedia.org/wiki/Special:WantedPages

It's basically just a list of pages that are linked to but don't yet
exist. That workflow allows editors to brain dump, link pages as they
go, then come back days later to fill in broken links from across the
_whole_ wiki without having to look for them.

> BTW, why are the public keys available publicly?
>
> I mean, I understand it should be harmless, but I expect that srht
> wouldn't expose it just because it's supposed to be harmless: there's
> presumably some good reason/usecase to expose it.

I personally use the feature in some infrastructure tasks. I can just
curl the URL and pipe it to .ssh/authorized_keys and I know all of my
active keys will be there. This is especially useful when collaborating
with other people; I can just list some usernames in my automation and
it will create their users and fetch their keys then periodically
refresh them.

Thank you all for the feedback. I've incorporated some of the
suggestions and published the post :)

https://secluded.site/pull-vs-push-intentional-notifications/

Hello all o/

I've drafted a new blog post, but would like some more eyes on it before
I publish. Any feedback is welcome :)

https://paste.sr.ht/~amolith/a06295a53b2397345c4ecd5f9c4038e3709d3f66

Cheers,
Amolith

Ingo Hoffmann <ingo@hoffmann.cx> writes:
> I see where you're coming from. My main concern is that, IMHO, billing should
> be more protected/has an extra layer of security.

I had the same concern while initially reading the proposal. I checked
the billing page and, personally, wouldn't have a huge problem with any
of my employees having read-only access to the information here. It
shows card type, last four digits, postal code, expiration month, and
when you paid how much. If it showed more sensitive information, like
more of the card details, I would absolutely want some knob to twist to
disable read access.

_Ideally_, that page could be hidden from all but a select few people