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
137
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
-
@douwe@waag.social Christine Lemmer-Webber did a great analysis a while ago:
https://dustycloud.org/blog/how-decentralized-is-bluesky/
It's a great place to start.
-
Trying to better understand ATproto and Activitypub similarities and differences.
People here with recent reading/listening/watch tips?
#fediverse #eurosky #bluesky #activitypub #ATProto #Mastodon
-
definitely not a fan of this. tbh, there should just not be a global feed that new accounts see, because they see a lot of stuff they don't understand or know the community norms for, and that leads to bad engagement.
-
There is the Web Share API, and the future Web Share Targets API, but I think we could also align Web Share with FedCM and be able to say "I want to share to this type of application"
-
@reiver i think the disjunction between Object and Link was actually unnecessary. https://github.com/w3c/activitystreams/issues/666
i also think there's too much emphasis on types when there really shouldn't be -- it's the *properties* that you end up using almost all of the time. pretty much the only types that actually matter are the Activity types (because you can't infer those).
-
-
@reiver Did you and I discuss queryfy a while ago, or was it one of my other projects?
Just wondering whether I owe you a heads up since queryfy has been bumped up to v0.3.0
-
With ActivityPub / ActivityStreams...
To me, it feels like there should have been something that is a common parent of both 'Object' and 'Link'.
That just had the "name", "nameMap", and "preview" fields (along with "id" and "type, of course) — since that is what 'Object' and 'Link' share in common.
I'll just call this common parent: 'Entity'.
...
It could have even been an opportunity to talk about how to handle unknown types.
