Just woke up and learned about #fedified. 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
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
@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 https://www.hyperledger.org/learn/publications/kiva-case-study 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.
@KevinMarks built a browser version for this type of rel-me distributed verification which is clever: https://www.kevinmarks.com/distributed-verify.html
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: https://huffduffer.com/chrisaldrich (Importantly, I don't have to type in/maintain any of the "elsewhere" profile section.)
More details & examples here: https://indieweb.org/rel-me
@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?
@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.
@darius hang on lemme scroll through all 4000 words of https://book.keybase.io/guides/proof-integration-guide
@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" 😅
@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 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 journa.host (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 jounallist.net 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?
Hometown is adapted from Mastodon, a decentralized social network with no ads, no corporate surveillance, and ethical design.