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