Post AQK3ha2ncS2NugPDwe by filippo@mastodon.social
(DIR) More posts by filippo@mastodon.social
(DIR) Post #AQK3hZWtX4W6JjTkDQ by filippo@mastodon.social
2022-12-05T17:17:45Z
0 likes, 0 repeats
Sigh. The architecture of the fediverse is even more hostile to self-hosting than I thought.I already knew you can't have multiple identity domains (the ones in the username) hosted at the same instance.TIL that while Mastodon considers the identity domain canonical, Pleroma tracks the URL the API is hosted at.In email terms, it's as if your identity was tied to the domain you access your webmail at.https://github.com/mastodon/mastodon/issues/5774#issuecomment-1337381347https://git.pleroma.social/pleroma/pleroma/-/merge_requests/294#note_4915
(DIR) Post #AQK3ha2ncS2NugPDwe by filippo@mastodon.social
2022-12-05T17:21:25Z
0 likes, 0 repeats
In practice it means that I can't have @filippo@filippo.io as my username, and then delegate it to a masto.host instance I access at, say, filippo.masto.host. I need to put the instance on a domain I control and never change, with all the risks involved in delegating a subdomain.For a network that compares itself to email and preaches "own your identity" it certainly makes it hard, unless you go straight for the true and pure solution of self-hosting everything. Users need graceful on-ramps.
(DIR) Post #AQK3haa7cYgza1zpsu by filippo@mastodon.social
2022-12-05T17:38:57Z
0 likes, 0 repeats
Like, imagine if having your email address alice@example.com hosted on Gmail meant that some email implementations forever remembered you as alice@aspmx.l.google.com with no way to change that. That's how Pleroma works, apparently as mandated by the ActivityPub spec.
(DIR) Post #AQK3hb3XrAED3HlKkK by niels@vrij.social
2022-12-06T07:13:02Z
0 likes, 0 repeats
@filippo agreed. Some analog to the MX record would be nice. Matrix does this better, bit still not as convenient as email. It’s not too late though. With sufficient community support you could have this implemented.
(DIR) Post #AQKt1D6BjamaCg6nQ0 by mikalai@discuss.systems
2022-12-06T16:48:00Z
0 likes, 0 repeats
@niels @filippo For utility protocols in 3NWeb group of protocols ( https://opensource.ieee.org/3nweb/architecture/-/blob/main/etc/3NWeb-overview.pdf ), in DNS we use TXT record in a form "<service>=<url>".e.g.$ dig TXT 3nweb.com...;; ANSWER SECTION:3nweb.com.21600INTXT"asmail=3nweb.net/asmail"3nweb.com.21600INTXT"3nstorage=3nweb.net/3nstorage"3nweb.com.21600INTXT"mailerid=mailerid.org"Experience has been good. A person can just own domain without running any servers. And for an enthusiast, who may have different ports or routes (paths) dedicated to particular services TXT format also looks simpler.What about making a user-oriented simple approach for other services?A person writes simple "<service>=<url>", and provider at that url can do "priority" "weight" on their side.Or, can it be even easier? Cause easier for user_in_control is the goal.
(DIR) Post #AQKugL0xJDnea2ptyK by mikalai@discuss.systems
2022-12-06T17:06:43Z
0 likes, 0 repeats
@niels @filippo Let's sketch a path for Mastodon to implement user-controlled domain-anchored id.Case of existing user, who wants to rename to own id (migrated case).Example: - @user@discuss.systems wants to have @user@user.domain - user.domain should have simple DNS record pointing to current provider of mastodon service - @discuss.system may keep a courtesy record to direct queries @user@discuss.systems to @user@user.domainCase of user with just own id. - All queries start with looking at DNS.Case of users on domain of instance. - It works as now.Now, servers should learn to handle users with different domains in id. May be in protocol it will need cached_from_dns value of provider going together with user's id.