Re: Trust.txt: Why another random .txt when we've got WebFinger and well-known URIs?

Bob, and the group...

Just to be clear, I am not running on a platform of trust.txt.

On page 8 of the spec., we encourage the use of "/well-known" so we are
clearly not against that.

The short answer to why we went with a text file is that we are working
with some extremely unsophisticated publishers. Take, for instance, the
publisher of the Hays Free Press, whom I met recently in Texas. She prints
news from her town on paper once a week, and maintains a website. As we all
know, when local news dies, news consumers fill in that vacuum with crap.
If she stops publishing, well, it would be bad, so we want to make things
as easy as possible for her and those like her doing the esteemable work of
keeping local journalism alive.

In my conversation with her, she was willing to post a file
<https://haysfreepress.com/trust.txt> in part because she already knew
about ads.txt, and so this was familiar to her. If I tried to start telling
her about RFC 7033, I would have lost her for sure. You are certainly right
that JRDs would be technically superior, but robots.txt has been around for
20+ years and the most entry-level web publisher knows about how it works.


Thank you for looking into trust.txt, and while I don't want people to vote
for me based on what they think of trust.txt, I think your question serves
as a useful model of why I am running. If you think that any new proposal
that is working to fix disinformation should follow, for example, the most
current standardized systems, you should voice that to the group. If the
group agrees, then that will be a part of how trust.txt -- and every other
effort out there -- will be evaluated.

-Scott Yates
Founder
JournalList.net, caretaker of the trust.txt framework
202-742-6842
Short Video Explanation of trust.txt <https://youtu.be/lunOBapQxpU>


On Sun, Aug 1, 2021 at 11:53 AM Bob Wyman <bob@wyman.us> wrote:

> Scott Yates, in his statement of candidacy
> <https://lists.w3.org/Archives/Public/public-credibility/2021Aug/0000.html>,
> includes a description of the trust.txt file
> <https://journallist.net/reference-document-for-trust-txt-specifications>.
>
> Please explain why it makes sense to introduce yet-another .txt file (in
> addition to robots.txt and ads.txt) when we have established procedures to
> allow those who control URIs to make statements supported by that control.
> For instance, RFC 5785 <https://datatracker.ietf.org/doc/html/rfc5785> defines
> the "/.well-known/" path prefix for "well-known locations" which are
> accessed via URIs. It seems to me that if one were to publish a trust.txt
> file, then it should be at the location "/.well-known/trust.txt" That does
> not seem to be the current proposal. Why are existing standards not being
> followed?
>
> It also seems to me that the proposed file format is an unnecessary
> departure from existing standards such as RFC 7033
> <https://datatracker.ietf.org/doc/html/rfc7033>, which defined WebFinger,
> a mechanism that could be easily used to carry the data which the
> proponents of trust.txt seek to make available. To make WebFinger do what
> trust.txt intends, it would be only necessary to register a few new JSON
> Resource Descriptors (JRDs), properties, or link-relations (i.e. belong-to,
> control, social, member, etc.). This sort of extension is provided for in
> the definition of RFC 7033 and in RFC 5988
> <https://datatracker.ietf.org/doc/html/rfc5988>, which defines "Web
> Linking" mechanisms. Note: The existing set of defined link-relations can
> be found in the IANA maintained link-relations registry
> <https://www.iana.org/assignments/link-relations/link-relations.xhtml>.
>
> While there will be a never-ending need to add support for new kinds of
> standardized statements, discoverable in well-known locations, I think we
> should be careful to ensure that new kinds of statements make use of
> existing standards rather than define entirely new mechanisms. I can't see
> anything in the trust.txt specification that actually requires a unique,
> non-standard approach that is not already supported by the various
> standards referenced above.
>
> bob wyman
>
>