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
-
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
-
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
and no it doesn't require emitting and processing 100,000
Moveactivities to 10,000 instances at once -
and no it doesn't require emitting and processing 100,000
Moveactivities to 10,000 instances at oncei think i'm supposed to direct discussion here, but i also linked back here from there, so idk in the spirit of everything being everywhere as far as i'm concerned go hogwild and yell at me online wherever you want
https://socialhub.activitypub.rocks/t/fep-1580-move-actor-objects-with-a-migration-collection/8111
-
i think i'm supposed to direct discussion here, but i also linked back here from there, so idk in the spirit of everything being everywhere as far as i'm concerned go hogwild and yell at me online wherever you want
https://socialhub.activitypub.rocks/t/fep-1580-move-actor-objects-with-a-migration-collection/8111
i'm almost disappointed bc it's so simple and obvious. there are a lot of caveats and requirements there because i was trying to make it clear enough to be implementable, but really it's as simple as doing this: https://neuromatch.social/@jonny/115338330944599542
-
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
> The mapping from old to new URIs is not knowable in advance, as the local IDs used by one instance software need not map onto the IDs used by another[...]
@jonny frankly you're making it more difficult for yourself here. There's no actual reason why regenerating all IDs should be necessary.
You're forcing the new server to do processing for every moved object, which is very inefficient.
A good proposal should try to make the whole move in one batch. Keep the existing ID paths and mitigate against collisions by having them namespaced properly in the first place (which I think most servers kinda do already).
-
> The mapping from old to new URIs is not knowable in advance, as the local IDs used by one instance software need not map onto the IDs used by another[...]
@jonny frankly you're making it more difficult for yourself here. There's no actual reason why regenerating all IDs should be necessary.
You're forcing the new server to do processing for every moved object, which is very inefficient.
A good proposal should try to make the whole move in one batch. Keep the existing ID paths and mitigate against collisions by having them namespaced properly in the first place (which I think most servers kinda do already).
@mariusor cool well i figured that the URI mapping step (which is cheap) was a good compromise vs "modifying the URI structure in every existing fediverse app to support proper namespacing" especially since you do need to hit each object to update the proofs anyway, but note taken.
-
> The mapping from old to new URIs is not knowable in advance, as the local IDs used by one instance software need not map onto the IDs used by another[...]
@jonny frankly you're making it more difficult for yourself here. There's no actual reason why regenerating all IDs should be necessary.
You're forcing the new server to do processing for every moved object, which is very inefficient.
A good proposal should try to make the whole move in one batch. Keep the existing ID paths and mitigate against collisions by having them namespaced properly in the first place (which I think most servers kinda do already).
-
@kopper @mariusor this FEP is totally orthogonal to other FEPs that make migration unnecessary, including by giving objects content addresses, which i would definitely prefer. this FEP addresses a huge problem given the current state of fedi software, but yes ideally things would have already been done better.
-
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 still reading so not everything but:Supporting instances MUST indicate their support of this FEP by including its namespace in the @context of affected Actor objects.
the recent archive.org downtime made all objects with contexts containing purl.org URLs completely unfederatable for any json-ld handling software. i really recommend not MUST-ing this -
@jonny still reading so not everything but:
Supporting instances MUST indicate their support of this FEP by including its namespace in the @context of affected Actor objects.
the recent archive.org downtime made all objects with contexts containing purl.org URLs completely unfederatable for any json-ld handling software. i really recommend not MUST-ing this@kopper i was looking for an instance metadata item that was just some list of tokens that was "the list of things that the instance supports," and i could have sworn it existed, but i couldn't find it when i looked. most fedi apps (and even most LD apps) don't actually dereference the URIs in a context and treat them as tokens anyway, but yes failure to resolve terms is a big problem and am not a fan of DNS-based linked data.
-
-
@mariusor not speaking for @kopper , but there's a longstanding problem that linked data doesn't do namespacing and doesn't handle relative locations/identities at all, and that bleeds into activitypub and fedi app design. so like fully agreed that it would be way more convenient to just be able to pick up a whole subtree that includes all my posts and move it over there because all the relationships between things are relative to a single root, but it don't work that way atm unfortunately
-
@kopper i was looking for an instance metadata item that was just some list of tokens that was "the list of things that the instance supports," and i could have sworn it existed, but i couldn't find it when i looked. most fedi apps (and even most LD apps) don't actually dereference the URIs in a context and treat them as tokens anyway, but yes failure to resolve terms is a big problem and am not a fan of DNS-based linked data.
@jonny feature-detection based on the moves and migration collections' presence would be enough for this purpose i'd think? -
@jonny feature-detection based on the moves and migration collections' presence would be enough for this purpose i'd think?
@kopper ya that's what i landed on - it's effectively the same as requiring the vocabulary to be declared in the context, since the properties
movesandmigrationwould otherwise be undefined in the json-ld document. i still would just like to have a standard way of declaring instance capabilities (and i could have sworn there already was one) so there's an unambiguous, easily resolved way of checking "does the instance know about this" without having to happen upon it by refreshing a migrated account -
@mariusor not speaking for @kopper , but there's a longstanding problem that linked data doesn't do namespacing and doesn't handle relative locations/identities at all, and that bleeds into activitypub and fedi app design. so like fully agreed that it would be way more convenient to just be able to pick up a whole subtree that includes all my posts and move it over there because all the relationships between things are relative to a single root, but it don't work that way atm unfortunately
@jonny @mariusor from what i can tell the only reason the origin based security model and it's problems are a thing at all is because there is no mechanism to see who "owns" an object from a reference alone, which namespacing would solve
otherwise you have to fetch every single object ever referenced just to check for a backlink. not only is fetching over AP is already inefficient as it is with no batching and surprisingly slow crypto, nobody serves backlinks of any kind -
@jonny @mariusor from what i can tell the only reason the origin based security model and it's problems are a thing at all is because there is no mechanism to see who "owns" an object from a reference alone, which namespacing would solve
otherwise you have to fetch every single object ever referenced just to check for a backlink. not only is fetching over AP is already inefficient as it is with no batching and surprisingly slow crypto, nobody serves backlinks of any kind -
@jonny that's how I do it in ONI. But because it's a service that supports client to server the ID of the object can be generated in the client (or by the user) when they submit the Create activity.
See here an example: https://marius.federated.id/uploads/big-air-package (you can CURL that as ActivityPub IRI, or in a browser as HTML or directly access the image with the Accept: image/jpeg header)
-
@jonny @mariusor from what i can tell the only reason the origin based security model and it's problems are a thing at all is because there is no mechanism to see who "owns" an object from a reference alone, which namespacing would solve
otherwise you have to fetch every single object ever referenced just to check for a backlink. not only is fetching over AP is already inefficient as it is with no batching and surprisingly slow crypto, nobody serves backlinks of any kind@kopper TY. :)
And fetching every single object in order to check who owns it should be the norm when that's relevant.
And quoting form your post on the activitypub.rocks forum:
> Therefore, if a user can create an actor-like object with private keys in their control, they can impersonate any other actor on their instance.
I don't follow your explanation. Maybe it's because I never plan to support request time fully dynamic JSON-LD contexts, because for the type of API I want to use for GoActivityPub, the best I'll be able to do is compilation time dynamic.
-
@kopper TY. :)
And fetching every single object in order to check who owns it should be the norm when that's relevant.
And quoting form your post on the activitypub.rocks forum:
> Therefore, if a user can create an actor-like object with private keys in their control, they can impersonate any other actor on their instance.
I don't follow your explanation. Maybe it's because I never plan to support request time fully dynamic JSON-LD contexts, because for the type of API I want to use for GoActivityPub, the best I'll be able to do is compilation time dynamic.
@mariusor this only becomes an issue for software which aims to be completely generic, with little to no knowledge on the objects being stored in them. if that is not a goal then you don't need to worry about this attack on your own actors -
@mariusor this only becomes an issue for software which aims to be completely generic, with little to no knowledge on the objects being stored in them. if that is not a goal then you don't need to worry about this attack on your own actors
@kopper I saw that the code you posted as an example for the issue was C#.
Do you maybe have a solution on how to make the dynamic nature of JSON-LD documents play nice with static typing and low overhead data types for the Activity Vocabulary?
For GoActivityPub I want an object in the vocabulary to correspond to an identically structured data type.
So far I can only think of compile time metaprogramming to generate these types based on a known list of JSON-LD contexts, but maybe I'm not seeing the whole picture.
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.
