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
125
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
-
The answer is vigorous code review. Anything that connects to an API, anything that is federated, shared, made free, or made at all should be reviewed for intent, for mistakes, for data integrity, for documentation and for competence. I don't care who or what creates it. Without code review, it's so untrustworthy that it poisons the well.
-
@stegodon What can I do while staying compatible with HTTP/1.1? https://github.com/astro/buzzrelay/blob/main/src/send.rs#L37
-
TIL: FediBuzz sends both :authority AND Host headers in HTTP/2 requests. old nginx rejects this as "duplicate". Both are kinda wrong - HTTP/2 replaced Host with :authority, but nginx shouldn't reject matching values. Fixed by upgrading nginx to 1.29+
-
@stegodon Sounds similar to my issue https://github.com/astro/buzzrelay/issues/132
>hyper/reqwest
I assume it's one their side (because Stegodon is written in Go)?
-
@smallcircles @fedicat @reiver
The question is: Do people even know what they are doing? Can they guarantee and ensure reliability, security, data protection and smooth operation in a network?
-
@reiver Even if you want to help I would avoid doing anything specific to whatever practice happens to be the fad this week. Clear documentation, example code, conformance tests, etc, all benefit every developer.
-
@reiver @josemurilo I voted Yes! But let me explain my point of view.
I have been programming for over 15 years… but I am also an #AuDHD who was diagnosed less than five years ago. Also I've been involved in an accident that affected my whole left arm. I can still type with it, but too much of it results in long periods of pain.
Also, besides working with computers, I am a full-time nurse student.
There are so many things I want to code, but I simply don't have the time or energy to do it. Telling an AI to create a simple loop, a class or even a module boilerplate really helps me a lot!
So, please, do help me!
-
🔧 Devlog: FediBuzz relay returned 400 errors. Root cause: nginx 1.18 + HTTP/2 + hyper/reqwest sent duplicate Host/:authority headers. Fixed by upgrading to nginx 1.29.4 which handles HTTP/2 headers correctly (fix from Aug 2025). #fediverse #activitypub #devlog
