Just woke up and learned about . I literally work at my day job on technology to aid verification of sources and let me tell you: it seems like a pretty big hack of a project that misses the point. Basically you have to trust the humans who run that site. What we actually need is buy-in from organizations to provide rel=me linkbacks to their various representatives. And for unaffiliated people who want verification, you add it to your website. That's it. We already have it on Mastodon

I saw the creator of say "well you can just buy any old domain name and pretend to be whatever org you want" and like... Uh you can check that against a Google search easily. There's no way to know that I can trust whoever is running or to verify THEIR claims

Funny thing: I was going to set up some meetings at work this morning to talk with, you know, actual experts on content and identity verification to see if we can come up with some tools to AID rather than SUPPLANT the already rather good and decentralized system we have. (For example, your employer might literally just be unwilling to add a rel=me for you for baroque IT reasons. So how do we make that easier for them? Etc)

Anyway I'm still gonna do this

And yes "you can check that on Google easily" implies that Google can be trusted and it can't all the time. Ultimately at some point you do have to simply trust SOMEone, SOMEwhere. What I'm saying is that I don't trust a random person who bought a domain with "fedi" in the name and set up a directory

Been talking to people at work about this whole verification thing and I was pointed to this really interesting specification for "trust.txt" -- basically a "robots.txt" and I could imagine it augmenting the rel=me thing that Mastodon already does. nytimes dot com could list their associated journalists' social media at this endpoint and Mastodon could do a handshake with that, similar to what it does with rel=me

But also: this could be a mass harassment vector for journalists! Someone goes to trust.txt, scrapes every account there, and harasses them.

But I do think that once you say in an official capacity "I am affiliated with [org]", you have to assume that anyone can find that info and can and will scrape it even if there isn't a directory available. idk. tough design space

@darius I'd honestly describe fedified as an actual attack, in the infosec sense, on the integrity of the decentralized self-verification system

@smadin @darius I think it is an attack, though likely not a malicious one. People are so accustomed to the idea that everything is a centralized platform they don't really consider something "real" unless there's a central authority, even when that doesn't make sense.

@notafurry @darius I agree it's probably more likely to be cluelessness than malice, but the site's FAQ implying that all rel=me verification that doesn't rely on fedified dot com is inherently suspect, does raise some red flags.

@darius Thank you! Some more humans and money for projects like @keyoxide could go a long way....

Indeed, cryptographically signed proofs like those that Keyoxide supports are the way to go.
@darius @keyoxide

@erAck 💯 ... I'm down to do whatever I can to support making that more user-friendly!

@darius @keyoxide

@darius ignoring the snake oil of web3.0 / nft rubbish that undermines it… identity is an area where blockchain as a technology could work well if you’re trying to maintain decentralised trust.

@mentor @darius I think this is entirely orthogonal to what blockchain can do and tries to do.
With blockchain, you have a transaction that can be reliably, consistently and with no repudiation traced back to a given actor. What it *doesn't* give you is any way to reliably tie that actor to a person, brand or reputation outside the blockchain.

@lisardggy @darius you’re seeking to establish trust in an identity, without exposing the original (sensitive) documentation to others. You’d back off against a series of externally recognised identity providers in the real world. See as an example.

@darius Awesome! we have many "trusted" sites we already use that could provide rel=me on their site. LinkedIn being one of them.

@jasontucker @darius could you explain what that means for #newbie like me who's also not a famous person

@Sainteetpoete @jasontucker if LinkedIn allowed you to put a special piece of code in your LinkedIn profile, then you would automatically get a little check mark on your Mastodon profile next to your LinkedIn link on your profile.

Mastodon supports this already, but LinkedIn would need to as well

@darius @Sainteetpoete There are other websites this could be helpful as well for instance a book publisher could allow you to put a link to your mastodon if you are an author or an accreditation site could show you are who you say you are if you work in a field with accreditation.

@darius @Sainteetpoete An actor could add the rel=me to their IMDB profile proving they are who they say they are. There is a bunch of ways to do this for various industries. I work in tech so linkedin would be a good one for me.

@jasontucker @Sainteetpoete yes, basically any site that you want to "verify" you could have that special kind of link on it. But each one would need to support it first, so at the moment it's really only good for verifying personal websites

@darius @jasontucker . This would be really cool. Because for all of the craziness of the bird app, the one thing we could be sure of is that people who were verified were who they said they were. At least pre Elmo

@Sainteetpoete @darius Yup, using a 3rd party site that people in your space recomize as a place that only you can make a change to (your personal website, linkedin, IMDB, your book publishers website) would help prove you are who you say you are.

@jasontucker @Sainteetpoete @darius

@KevinMarks built a browser version for this type of rel-me distributed verification which is clever:

One of my favorite uses is on Huffduffer from @adactio. I give the service my website and it automatically fetches all my linked social services via rel-me. Example: (Importantly, I don't have to type in/maintain any of the "elsewhere" profile section.)

More details & examples here:

@jasontucker @Sainteetpoete @darius

Incidentally, @KevinMarks is the reason that Mastodon includes/uses rel-me for this type of verification scheme. Thanks Kevin!

@erAck @darius I only brought up LinkedIn because it’s a place that many people list their CV.

@darius Any thoughts of adding something like the old PGP Web of Trust concept? Solve Mastodon's verification problem and *also* solve PGP's key distribution problem?

@admin I don't know what that is but I'll look it up

@darius simple version: if Alice trusts Bob, Bob tells Alice that he trusts Charlie, then Alice can trust Charlie. If Bob tells Alice he distrusts Eve, then Alice knows not to trust Eve either.

In a more complex setup you could let Alice say she has 40% trust in Charlie and 80% trust in Dave, so if Charlie trusts Eve but Dave says Eve is dangerous, then Alice would distrust Eve because she trusts Dave's judgment more than Charlie's.

Many Mastodon instances already share what instances they limit or suspend...if that was accessible through an API then creation of limit/suspend lists could be automated for instance admins by choosing a few starting instances that they trust; and new instances could get "verified" by only needing one or a few known instances agree to trust them, so long as they did not act poorly enough to have that trust overruled by others.

@admin ah, yes, I was a (distant) advisor on a master's thesis that was similar to this

@darius or random people with servers—that issue of trust is what has held up some people I know from joining Mastodon

@darius many things benefit from hiding their depth behind a simple and small surface. but trust really is one of those that benefit from making each link in the chain transparent. trust as a simple tiny interface is almost by necessity a lie.

@gekitsu @darius I think this is a VERY important point. And one that people intuitively understand offline, but not online. Perhaps because the signs are different from what we've evolved to understand.

For example, many would say you can trust the police (many -- including myself -- disagree, but that's another topic entirely lol.) But even so, if someone shows up at their door at 3am waving a badge and a gun and demanding to inspect their valuables, most people would still be rather suspicious. There is no single symbol of trust that can override suspicious circumstances; no one procedure we rely on for trustworthiness.

@darius funny, I actually tried to bring up this concerns to the original author, they blocked me without any notice...

@darius there's something interesting there. Thanks for sharing, filed in "folksprotocolonies" and labeled clearly "DO NOT ATTEMPT TO BIKESHED" 😅

@blaine I will whack you with the no-bikeshedding stick if I have to

@darius thank you. I know I can count on you. 🏑❤️

@darius it's probably too complex to have people run webfinger with a rel=me style field, but that would likely work well otherwise 🤔 .

@polymerwitch well, the fallback is a literal text file on the root of your domain. so someone could maintain that in excel and just export it as needed

@darius could the usernames optionally be hashed to prevent scraping?

@darius I'm interested in this idea, could you elaborate on it?

- What stops a malicious actor from spoofing a trust.txt and using that as validation in a similar way to phishing? ("verified by 'nytines' dot com", etc.) Would sites needs a whitelist of valid trust.txt sources?

- On a related topic to the harassment vector point you had: how would you sell trust.txt to orgs that are interested in verification but do not normally want contact exposure for some personnel? (ex. directors and exec)



- you're right, spoofing is simply always going to be a threat where DNS is involved, but also anyone could spoof the service that I mention in the original post too the same way. "fedifeid" or whatnot. solutions that get around that are huge crypto-based things that are unlikely to play nice with IT infrastructure at say, news orgs



- it's a necessary tradeoff. if an exec wants to say "I am truly CEO of CorpX on LinkedIn" then the point there is to publicly broadcast that that is who they are. This is about linking public profile information to public institutions (at least in the journalism context here)

@darius i guess the advantage of an instance like (or even a nytimes-specific instance) is that they could be keep an eye out for attacks targeting newsrooms' entire trust.txt lists and possibly handle it faster or more efficiently.

on the other hand, that might also overwhelm the moderation capabilities of a particular instance.

@darius To verify accounts associated with a public website (like newspapers or broadcasters):

You could diminish the "harassment" aspect by having the "trust.txt" document actually be a list of *hashed* accounts.

So when you want to verify whether an account is associated with a website, you can check this one-way (without being able to scrape the full trust.txt).

Is a fediverse address ? Oh, is it misspelt in your post?

What other fediverse servers can we browse that have a high collection of verified, ethical and unbiased journalists whose aim is Truth and Facts, not corporate sponsored propaganda?

Sign in to participate in the conversation
Friend Camp

Hometown is adapted from Mastodon, a decentralized social network with no ads, no corporate surveillance, and ethical design.