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
-
@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.
-
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
jonny@neuromatch.social FWIW there's no need to use SocialHub. You could post a discussion thread anywhere (like ActivityPub.Space, GitHub, a WordPress blog, etc... and yes, even a Mastodon status can be a starting point for discussion.)
-
@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> see who "owns" an object from a reference alone, which namespacing would solve
i don't think that's desirable on its own (since id should be opaque) but you can get it anyway if you require actors to have their own dns name (and then tls does the rest). that's how the same-origin model is *supposed* to work in theory; the bit that breaks the assumption is when one origin has multiple tenants
re: actor namespaces, i am writing/exploring a fep for that actually...
-
> see who "owns" an object from a reference alone, which namespacing would solve
i don't think that's desirable on its own (since id should be opaque) but you can get it anyway if you require actors to have their own dns name (and then tls does the rest). that's how the same-origin model is *supposed* to work in theory; the bit that breaks the assumption is when one origin has multiple tenants
re: actor namespaces, i am writing/exploring a fep for that actually...
-
@jonny @kopper @mariusor i've had the same wish, except instead of "actorPublicKey" it's any uri
basically take a base uri for your contact in your address book, and append a relative reference. the did specs can do this with service + relativeRef, and i think https://w3id.org/fep/e3e9 uses that? i'd like to be able to do that with cids too, or probably even http redirects
-
> see who "owns" an object from a reference alone, which namespacing would solve
i don't think that's desirable on its own (since id should be opaque) but you can get it anyway if you require actors to have their own dns name (and then tls does the rest). that's how the same-origin model is *supposed* to work in theory; the bit that breaks the assumption is when one origin has multiple tenants
re: actor namespaces, i am writing/exploring a fep for that actually...
@trwnh the way I meant namespacing object IDs was simply related to being able to decompose an IRI into a clean and intuitive structure: example.com/~jdoe/outbox/123, means that the activity with that ID can be said to be contained in jdoe's outbox on example.com.
-
@mariusor @kopper @jonny the uri owner in this case is example.com and you cannot assume that "~jdoe" or "/outbox/" mean anything special
...however, if you knew that /~jdoe was an actor, then /~jdoe can tell you that you can implicitly trust any attribution claims to /~jdoe if the resource exists within some prefix like /~jdoe/ or /objects/
-
@mariusor @kopper @jonny the uri owner in this case is example.com and you cannot assume that "~jdoe" or "/outbox/" mean anything special
...however, if you knew that /~jdoe was an actor, then /~jdoe can tell you that you can implicitly trust any attribution claims to /~jdoe if the resource exists within some prefix like /~jdoe/ or /objects/
> you cannot assume
@trwnh but I can. :D At least in GoActivityPub I built some logic around composing IRIs using this kind of mechanism.
It's not guaranteed for handling external objects, but it's useful for creating internal ones.
And in the context of moving objects (which is what I was replying to initially), I feel like having a example.com/~jdoe namespace ensures that you can do a batch move (and not have collisions) for all objects that have them as author just by changing the relevant bits of the object IDs, instead of having to generate a new ID individually for each moved object.
-
> you cannot assume
@trwnh but I can. :D At least in GoActivityPub I built some logic around composing IRIs using this kind of mechanism.
It's not guaranteed for handling external objects, but it's useful for creating internal ones.
And in the context of moving objects (which is what I was replying to initially), I feel like having a example.com/~jdoe namespace ensures that you can do a batch move (and not have collisions) for all objects that have them as author just by changing the relevant bits of the object IDs, instead of having to generate a new ID individually for each moved object.
@mariusor well, internally you control the identifiers, so you can do whatever you want. the danger is in assuming meaning externally.
-
@julian @jonny SocialHub is not a bad place though - FEP category is federated
https://socialhub.activitypub.rocks/ap/object/bee813d28b0947ffce97f8c2bbebb955
-
@julian @jonny SocialHub is not a bad place though - FEP category is federated
https://socialhub.activitypub.rocks/ap/object/bee813d28b0947ffce97f8c2bbebb955
Of course, not trying to say otherwise. Just that there is a preconception that jonny@neuromatch.social had to post there as part of the FEP process, which even I was under the assumption of.
We chatted about that and you disabused me of that notion :smirk:
-
@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@neuromatch.social kopper@not-brain.d.on-t.work Perhaps Capability Discovery is what you might be looking for? There is some implementor support for this one.
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
