[tech] A '.well-known/' path for contact information?

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

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

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

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

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 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

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

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

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

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'