Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you.
Technical Discussion
56
Posts
12
Posters
125
Views
-
This FEP is written to minimize the responsibility of the source instance,
You have this line right there in the spec, and I just don't understand this assumption.
By minimizing the responsibility of the Source instance, you're dumping all of the work on the Target and 3rd Party instances. But they're not the primary actors here.
The key parts of this chain are the Actor and the Source. They trust each other.
- They have an established User Agreement in place
- The Source has an established history of Actor behaviour
- The Actor has a high enough trust in the Source that they have published enough that it justifies migration
When Actor signs up for an account with Target, that new Target User Agreement doesn't assume that Actor is going to bring 200k old posts with them.
If I'm Target, I don't even want this. My default answer here is "no, you cannot do this without talking to me first". We don't have that relationship yet.
This frankly sounds like a giant spam vector.
Inherent in your specification is the assumption that Target's default stance is simply to accept all incoming transfer requests as legitimate.
This is a very Actor-centric view: "It's my content, I can bring it wherever I want, this should be as seamless as possible". But that's an oversimplification of the Publisher (Source) / Actor relationship that's actually in place.
And I don't think that's a fair assumption on behalf of Target. In fact, I don't even think it's a safe assumption for the network as a whole, because it's a giant spam vector. None of this is should be automatic, Target needs an active sign-off on content transfers.
I think this is relevant, because an active sign-off from both Source and Target actually changes parts of these specifications. They don't have to drip transfer, they can coordinate bulk operations, they can negotiate size limits, etc.
-
All these questions are addressed in the FEP except moderation
You and I seem to be reading different docs here.
I'm looking at FEP-73cd which looks like the best summary of the various complex cases and it still has several Required use cases that don't have an FEP specification. (table at the bottom)
I'm looking at FEP-1580 and it seems to be operating under the base assumption that "everyone is OK with this". It doesn't use the word "admin" or "administrator" even once. It never addresses "mod" or "moderator" as one of the players in this process.
The words "agreement" or "contract" appear zero times in the specification.
I'm talking with masto devs about what would be good there
That's a reasonable step, but again, I don't think that's the key problem. None of this matters without Masto Admins and Masto Mods also on board.
Every failure case in these specs falls on Admins and Mods to resolve, shouldn't they be first consulted?
It doesn't use the word "admin" or "administrator" even once. It never addresses "mod" or "moderator" as one of the players in this process.
This is why I said "except moderation" and then said "I'm working on it"
this is the least helpful feedback I've gotten, because you are indeed failing to read the document while also assuming that I haven't thought about the most basic parts of the problem.
-
This FEP is written to minimize the responsibility of the source instance,
You have this line right there in the spec, and I just don't understand this assumption.
By minimizing the responsibility of the Source instance, you're dumping all of the work on the Target and 3rd Party instances. But they're not the primary actors here.
The key parts of this chain are the Actor and the Source. They trust each other.
- They have an established User Agreement in place
- The Source has an established history of Actor behaviour
- The Actor has a high enough trust in the Source that they have published enough that it justifies migration
When Actor signs up for an account with Target, that new Target User Agreement doesn't assume that Actor is going to bring 200k old posts with them.
If I'm Target, I don't even want this. My default answer here is "no, you cannot do this without talking to me first". We don't have that relationship yet.
This frankly sounds like a giant spam vector.
@gatesvp
I dont even know where to start with this because its just based on fully mis-understanding the document -
Inherent in your specification is the assumption that Target's default stance is simply to accept all incoming transfer requests as legitimate.
This is a very Actor-centric view: "It's my content, I can bring it wherever I want, this should be as seamless as possible". But that's an oversimplification of the Publisher (Source) / Actor relationship that's actually in place.
And I don't think that's a fair assumption on behalf of Target. In fact, I don't even think it's a safe assumption for the network as a whole, because it's a giant spam vector. None of this is should be automatic, Target needs an active sign-off on content transfers.
I think this is relevant, because an active sign-off from both Source and Target actually changes parts of these specifications. They don't have to drip transfer, they can coordinate bulk operations, they can negotiate size limits, etc.
@gatesvp
Again, see how in my initial response I said "except moderation" and "I'm working on it"The entire move process already requires an active sign-off from the source and target actors, and this FEP provides a means of proving that. It also directly addresses the possibility of bulk transfers and does as much as is feasible, and there is already a discussion on how it could be made more efficient.
-
@gatesvp
Again, see how in my initial response I said "except moderation" and "I'm working on it"The entire move process already requires an active sign-off from the source and target actors, and this FEP provides a means of proving that. It also directly addresses the possibility of bulk transfers and does as much as is feasible, and there is already a discussion on how it could be made more efficient.
The entire move process already requires an active sign-off from the source and target actors,
But I'm not talking about the Source and Target Actors, I'm talking about the Source and Target Administrators. That's a different human.
Again, I just read all of these specs for the first time this morning, it's very possible I missed something here. You seem pretty confident that you have addressed Administrator concerns. And I'm happy to retract all of my comments and provide different and more useful feedback if you can even just clip a portion of the text that I missed with respect to the Administrators and help me get up to speed.
-
The entire move process already requires an active sign-off from the source and target actors,
But I'm not talking about the Source and Target Actors, I'm talking about the Source and Target Administrators. That's a different human.
Again, I just read all of these specs for the first time this morning, it's very possible I missed something here. You seem pretty confident that you have addressed Administrator concerns. And I'm happy to retract all of my comments and provide different and more useful feedback if you can even just clip a portion of the text that I missed with respect to the Administrators and help me get up to speed.
@gatesvp
I haven't yet addressed moderation and I am working on it. -
@gatesvp
I haven't yet addressed moderation and I am working on it.@jonny @gatesvp I have also only skimmed briefly through your proposed FEP, and I am also mortally offended that you have not proposed detailed technical solutions to every single problem that could possibly occur in a complex system comprised of many interacting components.
I must demand that you do so immediately, in a single toot, or I will feel morally obliged to berate you in my subsequent replies.
-
@jonny @gatesvp I have also only skimmed briefly through your proposed FEP, and I am also mortally offended that you have not proposed detailed technical solutions to every single problem that could possibly occur in a complex system comprised of many interacting components.
I must demand that you do so immediately, in a single toot, or I will feel morally obliged to berate you in my subsequent replies.
Look Mike, @FenTiger, I understand your sarcasm here. We are talking about public feedback on a public specification that affects multiple stakeholders.
This back and forth thread is making it clear that at least two of the stakeholders, Admins and Moderators, have not been consulted into this specification. While this doesn't seem like a "mortal offense", it does seem like a pretty significant roadblock.
If Admins don't agree to the spec, they're not going to roll it out on their servers. If they don't want this feature, nothing else matters.
So @jonny, I really appreciate you writing all this down. It is a lot of work and it is very useful for future devs to make something like this happen.
All of my feedback boils down to a simple thing.
Some portion of this spec needs to be drafted and signed by a few Admins from a couple of the larger fediverse instances. If they're not on board, this will never happen. If they are on board, their requirements are going to dictate many aspects of this spec.//
-
Look Mike, @FenTiger, I understand your sarcasm here. We are talking about public feedback on a public specification that affects multiple stakeholders.
This back and forth thread is making it clear that at least two of the stakeholders, Admins and Moderators, have not been consulted into this specification. While this doesn't seem like a "mortal offense", it does seem like a pretty significant roadblock.
If Admins don't agree to the spec, they're not going to roll it out on their servers. If they don't want this feature, nothing else matters.
So @jonny, I really appreciate you writing all this down. It is a lot of work and it is very useful for future devs to make something like this happen.
All of my feedback boils down to a simple thing.
Some portion of this spec needs to be drafted and signed by a few Admins from a couple of the larger fediverse instances. If they're not on board, this will never happen. If they are on board, their requirements are going to dictate many aspects of this spec.//
@gatesvp
@FenTiger
I am both of those stakeholders, and as I said repeatedly, I am working on some language regarding moderation controls/the tools admins will have.As with all FEPs, it is a proposal. There are likely to be many apps and instances that do not implement it. That is fine, and specific affordances are made for that. Indeed it is the case that there can be multiple proposals for how to accomplish this that work differently, everyone is welcome to write one, this is the nature of a proposal process.
Other admins and moderators have and will continue to make concrete criticisms and suggestions that have and will be integrated into this document which is explicitly marked as a work-in-progress.
-
@gaditb
I think both are needed and have their place. And in this case I am actually not sure if there is an opposing party to accidentally be perceived as yelling at - as far as I can tell people pretty universally agree that you should retain control of the things you said and did while moving around and not always lose everything (maybe there is some disagreement about what to move, but the FEP is purposely designed to leave that up to the implementation and ideally the actor)@gaditb can i add you to acknowledgements in the FEP?
-
Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.
criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.
https://codeberg.org/fediverse/fep/pulls/692
#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration
@jonny You boosted someone I think was saying good things about your post about your FEP but there's a warning and inability to see which of your posts it is:
-
@jonny You boosted someone I think was saying good things about your post about your FEP but there's a warning and inability to see which of your posts it is:
@Configures huh, weird, will check that out in the morning, thanks for letting me know. i assume still some bugs in the quote implementation
Gli ultimi otto messaggi ricevuti dalla Federazione
-
The answer is vigorous code review. Anything that connects to an API, anything that is federated, shared, made free, or made at all should be reviewed for intent, for mistakes, for data integrity, for documentation and for competence. I don't care who or what creates it. Without code review, it's so untrustworthy that it poisons the well.
-
@stegodon What can I do while staying compatible with HTTP/1.1? https://github.com/astro/buzzrelay/blob/main/src/send.rs#L37
-
TIL: FediBuzz sends both :authority AND Host headers in HTTP/2 requests. old nginx rejects this as "duplicate". Both are kinda wrong - HTTP/2 replaced Host with :authority, but nginx shouldn't reject matching values. Fixed by upgrading nginx to 1.29+
-
@stegodon Sounds similar to my issue https://github.com/astro/buzzrelay/issues/132
>hyper/reqwest
I assume it's one their side (because Stegodon is written in Go)?
-
@smallcircles @fedicat @reiver
The question is: Do people even know what they are doing? Can they guarantee and ensure reliability, security, data protection and smooth operation in a network?
-
@reiver Even if you want to help I would avoid doing anything specific to whatever practice happens to be the fad this week. Clear documentation, example code, conformance tests, etc, all benefit every developer.
-
@reiver @josemurilo I voted Yes! But let me explain my point of view.
I have been programming for over 15 years… but I am also an #AuDHD who was diagnosed less than five years ago. Also I've been involved in an accident that affected my whole left arm. I can still type with it, but too much of it results in long periods of pain.
Also, besides working with computers, I am a full-time nurse student.
There are so many things I want to code, but I simply don't have the time or energy to do it. Telling an AI to create a simple loop, a class or even a module boilerplate really helps me a lot!
So, please, do help me!
-
🔧 Devlog: FediBuzz relay returned 400 errors. Root cause: nginx 1.18 + HTTP/2 + hyper/reqwest sent duplicate Host/:authority headers. Fixed by upgrading to nginx 1.29.4 which handles HTTP/2 headers correctly (fix from Aug 2025). #fediverse #activitypub #devlog
