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
14
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.
@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
-
reiver@mastodon.social so, are we doing this?
-
fentiger@mastodon.social Flow control is the feature in TCP where the receiving host, in its ACK, can send back information about its remaining buffer space. The sending host can slow down its sending rate to prevent overflowing that buffer. If this works correctly, no error is ever sent.
-
In Activity Streams 2.0, we can represent the result of an activity using the result property. Here, when the actor accepts a Follow activity, the result is that the follower is added to the actor's followers collection.
{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://social.example/accept/12931", "type": "Accept", "actor": "https://social.example/person/24405", "to": ["as:Public", "https://other.example/person/21356"], "object": { "id": "https://other.example/follow/30360", "type": "Follow", "to": ["as:Public", "https://social.example/person/24405"], "actor": "https://other.example/person/21356", "object": "https://social.example/person/24405" }, "result": { "id": "https://social.example/add/11066", "type": "Add", "actor": "https://social.example/person/24405", "to": ["as:Public", "https://other.example/person/21356"], "object": "https://other.example/person/21356", "target": "https://social.example/person/24405/followers" } }My question is: how can the Add activity refer to the activity that caused it? I don't think we have a standard property for this. My best guess right now is context or maybe instrument, neither of which seems ideal. I think an extension inverse property, like resultOf, might be the best option.
-
I'm looking into federating out deletion of contexts because in NodeBB the concept of a topic is a discrete entity, not tied to the posts contained within. Deleting the top-level post would not alter the topic in any way, except perhaps that the next oldest reply is suddenly promoted to top-level, which is odd.
Conversely, in ActivityPub, there either is no concept of a context (threaded objects only), or merely the suggestion of one as a view (current implementations of resolvable contexts). I'm hoping to move this more towards contexts as discrete entities with their own activities.
-
@julian love to see the reports of cross project colab!
-
@elvecio Further investigation showed that this wasn't a Mastodon's fault. There was some weirdness on behalf of the originating instance.
Mastodon server received a post addressed to public and I received a post addressed to followers.
-
@silverpill
For superior control of your content, suggest to use hubzilla
-
@silverpill One thing that has always been different in Mike's software is that only authorized people can see non-public things. It is of little use to have the right address for the image, video, or file (as instead happens and happened in Mastodon Diaspora and others - almost all of them). In the software created by him, you cannot see even if you have an address/id or whatever you like.
