Embed this noticeCy (cy@fedicy.us.to)'s status on Saturday, 10-Feb-2024 23:27:10 JST
CyTrying to figure what I even want my program to do. Log on to multiple Fediverse instances, keep up with some timelines. How do I time it so it starts polling for updates, only after the oauth negotiation is done? How do I deal with sites randomly expiring tokens, so I'd have to negotate oauth again? You get a token and... start waiting for the next instance to be ready for polling, except that token is for a different instance, but does that matter, but...
When two accounts are linked to the same key, you can migrate your followers from one server to another even without permission from your old server. The migration process is very similar to what Mastodon and other popular AP servers already support, but it is a "pull" rather than "push". See this document for details: https://codeberg.org/fediverse/fep/src/branch/main/fep/7628/fep-7628.md
This was implemented in Mitra but (as I learned in the process) it is too little, too late. As @Hyolobrika pointed out I'm now working on FEP-ef61 that will make all content portable. It won't be necessary to "migrate" anything anymore because the location won't matter
...with paid subscriptions, donation buttons, and cryptocurrency, in #rust OK
@silverpill@mitra.social Account migrations (from one server to another). Identity can be detached from the server. I don't think this is possible, because of how HTTP signatures include the Host: header. Because HTTP signatures are the worst. But if you take a look at Friendica's support for moving instances, you can learn how not not not not not not notnot to do it. tl;dr using the private signing key your instance created, not creating your own, downloading that private key, then sending it to other instances is a bad bad bad bad inhales bad bad bad idea.
He is authoring standards that decouple posts from servers and allow posting the same post to multiple servers (presumably without your followers seeing duplicates). Also signing posts so that servers can’t tamper with them. And I can’t remember what else, if anything.
It’s part of his mission to make the fediverse as good as Nostr on the user autonomy front.
Hadn't heard, but I'm trying to make basically a fancy reaggregating client, so I can get posts from pdx.social and pnw.social and equestria.social and whatever else, as well as posts to fedicy.us.to. Ideally it'd let me direct everyone toward my main account, instead of posting as alt accounts and having to keep up with those too. But downloading notifications and private messages from alt accounts is also a thing I'd like to have. Most Fediverse clients throw away the info they download, so the servers can have more control over what you see, but that means downloading the timeline again every time you refresh the page.
And uh, also a little server I guess, just a single user instance. Is that sort of what @silverpill@mitra.social is doing?
>presumably without your followers seeing duplicates
As long as their software supports data portability or at least can de-duplicate posts. This is why I'm writing these proposals - to really fix the Fediverse we need a coalition of developers, ideally including big players like Mastodon.
Yes sorry, I didn't mean to say it wasn't possible. A securely signed key namespace is great and would totally work. I'm mostly complaining about HTTP signatures, and saying that hypothetically if your proposal is out of the question, then the absolute, minimal, most half-assed and barely functional way to enable smooth account migration is to just... stop signing HTTP headers. Signing HTTP headers along with the body, rather than just the body, is the only thing absolutely stopping us from migrating to a new account after the old instance dies. It serves no purpose other than making things difficult.