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.

[mariusor@metalhead.club]

> 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).

[jonny@neuromatch.social]

@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.

[kopper@not-brain.d.on-t.work]

@mariusor @jonny another problem requiring namespacing would've massively helped. and yet we must keep bikeshedding because the spec people say so

[kopper@not-brain.d.on-t.work]

@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@neuromatch.social]

@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@metalhead.club]

@kopper I don't understand your complaint here, nor the "subtle" dig at the spec writers.

@jonny

[jonny@neuromatch.social]

@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@not-brain.d.on-t.work]

@jonny feature-detection based on the moves and migration collections' presence would be enough for this purpose i'd think?

[jonny@neuromatch.social]

@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 moves and migration would 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

[kopper@not-brain.d.on-t.work]

@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@neuromatch.social]

@kopper @mariusor in my fediverse, objects are given absolute addresses like @{actorPublicKey}/whatever/i/want and displayed like {petName}/whatever/i/want

[mariusor@metalhead.club]

@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)

@kopper

[mariusor@metalhead.club]

@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@not-brain.d.on-t.work]

@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@metalhead.club]

@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.

[julian@activitypub.space]

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.)

[trwnh@mastodon.social]

@kopper @jonny @mariusor

> 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@mastodon.social]

@kopper @jonny @mariusor basic idea is similar to toot:attributionDomains but with prefixes instead. the part i'm exploring is whether it makes more sense to just say heck it and use containers instead

[trwnh@mastodon.social]

@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

[mariusor@metalhead.club]

@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.

@kopper @jonny