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
53
Posts
11
Posters
2
Views
-
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?
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.
-
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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
fentiger@mastodon.social yes I was also thinking of the venerable 429.
evan the thing is, both approaches rely on the receiving end to support it. I would make the argument that a 429 would have nominal support from some implementations, but then again I wouldn't actually bet money on it.
Either way you're looking at an FEP to establish flow control signalling or 429 handling. I'd then make the argument that putting together guidance for 429 (+ exponential back off) is easier than specifying flow control logic.
-
@evan No, you haven't. You just need to back off and retry, just as you do for an ACK timeout in TCP.
-
fentiger@mastodon.social yes, but by that point you've failed. What I want is to have more adaptive sending, so you don't get to the 429 code.
-
-
Obviously the other option is to keep sending until the receiving server fails, and then do exponential backoff until the remote server can process your activity again.
But I'm looking for something more adaptive that adjusts the sending rate before the receiver fails.
-
I've been thinking lately about flow control. That's a feature of some networks where a receiver can tell a sender to slow down its sending rate to match the receiver's processing rate.
In TCP flow control, the receiving host returns a receiving buffer size in its acknowledgement segment, so the sending host know how much data it can send without overflowing the buffer.
I wonder if there are ways that a receiving ActivityPub protocol server could tell the sending server to slow down? Maybe we could reuse some of the RateLimit headers.
Another option would be a special header that says how big your incoming activity queue is. "I have a very long processing queue right now, please keep stuff in your outgoing queue for a while."
-
@flancian It's an egregiously backwards-incompatible change, so probably no.
-
@julian Pages should be real containers, not slices of the collection like "last 25 items".
