💾 Archived View for soviet.circumlunar.space › oak › mailinglist › 9.gmi captured on 2024-06-16 at 12:59:01. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
Date: Thu, 7 Jan 2021 12:36:04 +1100
I've noticed a lot chatter recently about ways to allow comments on
posts. Sometimes the objective is to drop a message to the author,
sometimes to allow a public discussion.
I not personally interested in public comments, but I am very interested
making it easier for authors to be reached.
I've been wondering whether adopting a /.well-known/contact.txt
convention for sharing contact details. This idea has been blatantly
stolen from security.txt?. This will allow for things like:
- automated back-link notifications for authoring tools.
- with client support, users to respond to a page from within the
client.
- and emails addresses could be harvested en mass for nefarious
purposes.
A solution like this isn't obviously workable for public discussions,
but a commenting system could be cobbled together to ingest messages
received via SMTP. It may require additional conventions like a header
(or subject line) that hints to which post being discussed. It may also
require a way to signal that anything sent to the address will be
public.
To me, something like this feels more in spirit of Gemini, but really
who am I to say. :)
? https://en.wikipedia.org/wiki/Security.txt
--
Jon
--------
Date: Wed, 6 Jan 2021 21:02:26 -0500
It was thus said that the Great Jon once stated:
I've been wondering whether adopting a /.well-known/contact.txt
convention for sharing contact details. This idea has been blatantly
stolen from security.txt?.
? https://en.wikipedia.org/wiki/Security.txt
There's http://humanstxt.org/ that does what you want. You might want to
look into that format.
-spc
--------
Date: Wed, 06 Jan 2021 22:00:56 -0500
Jon <jon at shit.cx> writes:
I've been wondering whether adopting a /.well-known/contact.txt
convention for sharing contact details. This idea has been blatantly
stolen from security.txt?. This will allow for things like:
I think it's a good idea in principle, but it is maybe not well-suited
for multi-user sites, which a lot of Gemini sites are.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
--------
Date: Thu, 7 Jan 2021 14:25:41 +1100
On 06/01/21 21:02, Sean Conner wrote:
There's http://humanstxt.org/ that does what you want. You might want
to look into that format.
Yeah, that's what I'm looking for. Thanks.
humans.txt attributes everyone to everything. That's not really going to
allow an automated tool to extract the correct contact details for a
page. For that, something else is needed; either some sort of reference
in the source page, or a default human.
A default human would be good enough for domains where everything should
be attributed to one human which seems to be the norm around here.
The default human could simply be the first listed in humans.txt.
--
Jon
--------
Date: Thu, 7 Jan 2021 14:42:50 +1100
On 06/01/21 22:00, Jason McBrayer wrote:
I think it's a good idea in principle, but it is maybe not well-suited
for multi-user sites, which a lot of Gemini sites are.
Hmm. I assumed that most sites were on their own domain.
On a multi-tenanted host, is each tenant generally confined to a unix
homedir? For example `/~${USER}/*`. If that's the case, checking the
users root before hitting the root shouldn't be unreasonable.
--------
Date: Thu, 7 Jan 2021 02:25:09 -0500
It was thus said that the Great Jon once stated:
On 06/01/21 22:00, Jason McBrayer wrote:
> I think it's a good idea in principle, but it is maybe not well-suited
> for multi-user sites, which a lot of Gemini sites are.
Hmm. I assumed that most sites were on their own domain.
On a multi-tenanted host, is each tenant generally confined to a unix
homedir? For example `/~${USER}/*`. If that's the case, checking the
users root before hitting the root shouldn't be unreasonable.
It might not always be the case that a user's directory is marked by a
'~'. For instance, on <gemini://republic.cirumlunar.space/> users are under
<gemini://republic.circumlunar.space/users/>.
-spc
--------
Date: Thu, 7 Jan 2021 19:14:42 +1100
On 07/01/21 02:25, Sean Conner wrote:
It was thus said that the Great Jon once stated:
> On 06/01/21 22:00, Jason McBrayer wrote:
> > I think it's a good idea in principle, but it is maybe not
> > well-suited for multi-user sites, which a lot of Gemini sites are.
>
> Hmm. I assumed that most sites were on their own domain.
>
> On a multi-tenanted host, is each tenant generally confined to a
> unix homedir? For example `/~${USER}/*`. If that's the case,
> checking the users root before hitting the root shouldn't be
> unreasonable.
It might not always be the case that a user's directory is marked by
a '~'. For instance, on <gemini://republic.cirumlunar.space/> users
are under <gemini://republic.circumlunar.space/users/>.
-spc
I guess traversing up the tree looking for a humans.txt file would work.
Finding the humans.txt file for a document at
`/users/jon/gemlog/2021-01-07-a-new-doc/index.gmi` would search:
- /users/jon/gemlog/2021-01-07-a-new-doc/humans.txt
- /users/jon/gemlog/humans.txt
- /users/jon/humans.txt
- /users/humans.txt
- /humans.txt
This would allow one document, or an entire branch of the tree have a
different contact than the rest, but it's a lot more complex than simply
hitting up /humans.txt.
Even though it handles the edge cases, I'm less enthusiastic about this
solution. What was initially a simple task of fetching /humans.txt is,
well not that anymore.
--
Jon
--------
Date: Thu, 07 Jan 2021 11:03:28 +0100
Le jeudi 7 janvier 2021, 02:36:04 CET Jon a ?crit :
I've noticed a lot chatter recently about ways to allow comments on
posts. Sometimes the objective is to drop a message to the author,
sometimes to allow a public discussion.
I not personally interested in public comments, but I am very interested
making it easier for authors to be reached.
I've been wondering whether adopting a /.well-known/contact.txt
convention for sharing contact details. This idea has been blatantly
stolen from security.txt?. This will allow for things like:
- automated back-link notifications for authoring tools.
- with client support, users to respond to a page from within the
client.
- and emails addresses could be harvested en mass for nefarious
purposes.
There is an email field in the certificate for this, I don?t know about other authors, but I put my email in the email field of certificates for my capsules.
This does not work for multi-user domains, but as the rest of the thread shows, the *.txt solution does not easily support them either.
I also wanted to note that authors expecting comments by email using a specific subject syntax can just use a mailto link at the end of the article, and I?ve seen several gemlogs already doing this.
Example: gemini://ybad.name/log/2021-01-02.gmi (this one even use a mailing list for commenting it seems)
C?me
--------
Date: Fri, 8 Jan 2021 08:10:33 +1100
On 07/01/21 11:03, C?me Chilliet wrote:
There is an email field in the certificate for this, I don?t know
about other authors, but I put my email in the email field of
certificates for my capsules. This does not work for multi-user
domains, but as the rest of the thread shows, the *.txt solution does
not easily support them either.
That's something I hadn't considered. Can you change the email address
without invalidating your TOFU cert? If not, then changing contact
details will be difficult.
I also wanted to note that authors expecting comments by email using a
specific subject syntax can just use a mailto link at the end of the
article, and I?ve seen several gemlogs already doing this. Example:
gemini://ybad.name/log/2021-01-02.gmi (this one even use a mailing
list for commenting it seems)
That is something else I hadn't considered. But without formal way to
reliably scrape the contact details from a page, things aren't any
better than present. But that formality is certainly another approach
that could be taken. I remember a discussion how to know how the content
is licensed. One idea was a way to set key/value pairs that contains
this information. I'll try to dig up the thread. A solution for both
problems would be helpful.
Thank you for your ideas.
--
Jon
--------
Date: Fri, 8 Jan 2021 08:14:19 +1100
On 08/01/21 08:10, Jon wrote:
I remember a discussion how to know how the content is licensed. One
idea was a way to set key/value pairs that contains this information.
I'll try to dig up the thread.
The thread was titled '(proposal) on metadata in documents'
--------