24 comments
@gargron I'm confused about where the users' keys are supposed to be stored? They're not supposed to "enter low-security environments such as the browser?" But presumably there will be web clients that get temporary keys somehow. So unless users set up their own instance, someone else holds the key? Am I missing something??? For anyone looking for the #BlueSky code he's talking about: https://www.theverge.com/2022/5/4/23057473/twitter-bluesky-adx-release-open-source-decentralized-social-network My perspective is that of an implementer, not a protocol designer. It does seem overcomplicated for benefits that I would consider neglible. I disagree the most with depending on a "DID Consortium" to be able to participate in the network... @Gargron related thread on slashdot with mention of #mastodon https://news.slashdot.org/story/22/05/05/002249/twitters-decentralized-open-source-offshoot-releases-its-first-code @Gargron I'm baffled that they (and you, come to that) still use webfinger instead of profile URLs @kevinmarks @Gargron webfinger is easier to understand for users imo, it just shouldn't be canonical (it should be a pointer to some other, more stable identifier). there's nothing wrong with just using webfinger, at least as a way of addressing people @trwnh @Gargron I don't mean the @ syntax that you type, that's reasonable and autocompletes well, but as mastodon turns them into URL links when published, encouraging people to share the thing with 2 @'s rather then the URL elsewhere is very confusing, and using the webfinger protocol to map between them rather than a simple string replacement is unneeded overhead. @kevinmarks that's only true for mastodon URLs -- remote servers could have `@a@trwnh.com` map to `https://ap.trwnh.com/317390182739802718903` via webfinger, which contains neither the original username nor the original domain name. the `@user@domain` is the easiest way for people to share with people without worrying about what URL it will resolve to on the backend (or, in mastodon's case, *not* resolve to -- mastodon uses webfinger as canonical address, unfortunately, since it predates activitypub) @trwnh No, urls are the easiest to share, as you can click on them. And they resolve to have links in, which code can look for as well as people. @kevinmarks oh hmm, both trwnh.com and abdullahtarawneh.com are green ticks for me over here as far as webfinger resolving, i was giving a hypothetical example that is currently not valid but might be valid in the future when i get around to actually implementing my new (dynamic) website :roundboi: currently i just have *.trwnh.com dns resolving to trwnh.com and any unrecognized resource maps to 404 via nginx @kevinmarks fwiw what i was trying to say is that the human-friendly identifier (webfinger) should resolve to the machine-friendly identifier (activitypub id, which can be reasonably resolved via https and parsed by code) @trwnh but it isn't human friendly. @kevinmarks well again, that's dealing purely within the realm of mastodon, which i think we can agree does not strictly *need* webfinger, but i still think it is useful for interop note that the mastodon web domain and webfinger domain do not have to be the same, either -- i could host mastodon.trwnh.com and have a profile at mastodon.trwnh.com/@a, but still use the webfinger address a@trwnh.com for consistency with my email and xmpp (although with that said, i do not wish to run mastodon....) @Gargron any time I see an overly complicated architecture I once again wish there was more emphasis on energy footprint and #greensoftware in general. @Gargron is there redundancy in mastodon for accounts, keeping "followers" and "following" from being wiped if an admin just decides to self-destruct their server? I imagine that lack of redundancy might make it lack decentralization long-term. Having a designated backup server would be ideal. @Gargron I think the Merkle tree idea works for users who may want to change their instance and maintain the trust of their followers that the new account is theirs. I think this idea could easily be added to ActivityPub. @Gargron @sean That's one way to look at it, yes definitely; another though is to see it as practical (yet experimental) collaborative development towards social posts and social graph as migratable digital assets, and attempt at separating free speech from free reach... All still pie-in-the-sky (pun kinda intended), but still though. @Gargron it is much worse than activitypub as it is implemented today in terms of assured deniability 🙃 |
@Gargron Pardon my non-know-how, but what's a Merkle tree?