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
70
Views
-
@gaditb
Really good point, I have some ideas for language here, and there does need to be a bit more specificity about how to handle visibility for e.g. instance software that may not have blocks importing from software that does - basically that visibility must be at least as constrained as the source object@jonny Or at minimum alerted to the user, possible?
But does that even. make sense? Most of the stuff here is, because of FEPs' linage from RFCs, spoken in the language of protocols and behavior/format specifications -- is it coherent to define a part of the specifications as the... I guess, social protocol, interface, etc., of a compliant piece of software towards its users?
(On the one hand those are literally the original pre-computer definitions of "protocol" and "compliant", but on the other hand that is CLEARLY misusing the terms there.)
And even if it is coherent, is it possible to actually do it without becoming a "the Passkey people yelling at and threatening the Keepass devs"?
-
@jonny Or at minimum alerted to the user, possible?
But does that even. make sense? Most of the stuff here is, because of FEPs' linage from RFCs, spoken in the language of protocols and behavior/format specifications -- is it coherent to define a part of the specifications as the... I guess, social protocol, interface, etc., of a compliant piece of software towards its users?
(On the one hand those are literally the original pre-computer definitions of "protocol" and "compliant", but on the other hand that is CLEARLY misusing the terms there.)
And even if it is coherent, is it possible to actually do it without becoming a "the Passkey people yelling at and threatening the Keepass devs"?
@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) -
@gatesvp
All these questions are addressed in the FEP except moderation, and I'm talking with masto devs about what would be good thereAll 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?
-
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.
-
@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
-
Bridging has been a bit slower than usual, on and off, for the last few days. Apologies all! It should be mostly back to normal now, we’ve put some workarounds in place, and we expect to have a more permanent fix within a day or two. Sorry for the trouble, thank you for your patience with us!
-
Polls are rendering!
screenshot of the latest emoji poll rendered on the ktistec serverI'm working to get all of the little visual elements available across the Fediverse to render in a usable way on Ktistec. When released, users will also be able to vote on polls.
-
Okay, I've setup https://notes.socialcg.org/about
-
@julian i'd say the confusion is primarily that we've shifted topic around several different things and i'm still not sure which is the intended topic of the discussion :x
- deleting posts that are in a thread
- removing posts from a thread
- implications for downstream posts in a thread when some ancestor in the reply chain is deleted/removed
- deleting a thread that is in a forum
- removing a thread from a forum
- moving a thread to the "uncategorized" forum
- ...?
-
@julian if the intent is to signal what happens when nodebb moves a thread to "uncategorized", then i think the simplest thing is for nodebb to treat "uncategorized" as a forum in itself, still. you already assign them an id of -1, so you are in effect treating the "uncategorized" category as a category still.
-
@julian the confusing thing to me, though, is that both Delete and Remove already don't imply anything about posts in the thread if the thread is deleted/removed from the forum.
by default, if you Delete a thread, the forum might still have a broken link to the now-deleted thread, and the posts also have broken links to the thread.
by default, if you Remove a thread from the forum, the posts still exist within the thread.
-
trwnh@mastodon.social specifically however, is that you're not deleting the context. Just removing it.
NodeBB has the concept of a context not belonging to an audience (the "uncategorized" pseudo category.) in those specific situations, contexts would be removed from the audience, not deleted.
Lemmy and Piefed don't have these concepts, so they simply delete them. So therein lies some of the confusion I believe.
-
@julian like removing a whole thread from the forum? Remove(object=thread, target=forum)? this seems like something altogether different than removing posts from a thread.
removing threads from a forum is possible but if the thread is owned by the forum then the forum can also delete them.
the part that differs between impls is whether Delete(thing that is a context) should do anything to objects where context = the Delete.object, right? i think it makes the most sense to just orphan them.
