@naturzukunft@mastodon.social > rdf-pub.org is providing c2s
-
@naturzukunft@mastodon.social
> rdf-pub.org is providing c2sAwesome, so that's at least 3 server packages to test clients against. Pleroma, Epicyon, and rdf-pub.org.
-
@naturzukunft@mastodon.social
> rdf-pub.org is providing c2sAwesome, so that's at least 3 server packages to test clients against. Pleroma, Epicyon, and rdf-pub.org.
@strypey@mastodon.nzoss.nz fwiw I'm thinking that C2S might be applicable in an S2S-like setting where a user "logs in" to instance B using instance A's credentials, and B can do limited actions as the user on A. Essentially A would act as the server, B is the "client".
-
@strypey@mastodon.nzoss.nz fwiw I'm thinking that C2S might be applicable in an S2S-like setting where a user "logs in" to instance B using instance A's credentials, and B can do limited actions as the user on A. Essentially A would act as the server, B is the "client".
@julian @strypey one wonders if it would perhaps be more expedient to just do the identity bits and have the data live on B rather than ferrying it back to A.
probably what’s needed is a framework for tracking which resources are equivalent to each other. say i crosspost from my website to a forum. the post exists as two resources, one on each site, even though they are the “same” post. maybe as:alsoKnownAs can help here?
-
@julian @strypey one wonders if it would perhaps be more expedient to just do the identity bits and have the data live on B rather than ferrying it back to A.
probably what’s needed is a framework for tracking which resources are equivalent to each other. say i crosspost from my website to a forum. the post exists as two resources, one on each site, even though they are the “same” post. maybe as:alsoKnownAs can help here?
@trwnh@mastodon.social the idea behind B delegating actions for A to carry out is that A is the actual owner of the user, and can sign it accordingly (per same origin security)
There are object proofs but those aren't exactly easy to implement...
-
@trwnh@mastodon.social the idea behind B delegating actions for A to carry out is that A is the actual owner of the user, and can sign it accordingly (per same origin security)
There are object proofs but those aren't exactly easy to implement...
@julian yeah, A owns the user account on A, but B might have a separate user account on B. the same logical person might control both user accounts. if identity was federated, the same credentials could be used to sign into both user accounts equally.
in other words, imagine identity server I, which is used to sign in on both A and B.
you make a post P1, which is published as R1a on A, and R1b on B. what participants need to know is that both R1a and R1b are authentic.
-
@julian yeah, A owns the user account on A, but B might have a separate user account on B. the same logical person might control both user accounts. if identity was federated, the same credentials could be used to sign into both user accounts equally.
in other words, imagine identity server I, which is used to sign in on both A and B.
you make a post P1, which is published as R1a on A, and R1b on B. what participants need to know is that both R1a and R1b are authentic.
@trwnh@mastodon.social but why must a separate account be made? Account fragmentation is yet another unsolved problem because the new user on account B is functionally useless: no followers, etc. and the content isn't automatically available to the followers of the user on instance A.
-
@trwnh@mastodon.social but why must a separate account be made? Account fragmentation is yet another unsolved problem because the new user on account B is functionally useless: no followers, etc. and the content isn't automatically available to the followers of the user on instance A.
@julian it’s not a “must”, but it keeps data localized to where it will be used. the forum at B needs to keep at least a cached copy of P1. if A goes down, the cached copy at B still lives.
the user account at B can be logged into in potentially multiple ways; what matters for “fragmentation” is that anyone can tell when two resources are the “same”, i.e. they must be able to tell when two identities are equivalent. post P1 has url R1a and R1b and is attributed to Ua==Ub
-
@julian it’s not a “must”, but it keeps data localized to where it will be used. the forum at B needs to keep at least a cached copy of P1. if A goes down, the cached copy at B still lives.
the user account at B can be logged into in potentially multiple ways; what matters for “fragmentation” is that anyone can tell when two resources are the “same”, i.e. they must be able to tell when two identities are equivalent. post P1 has url R1a and R1b and is attributed to Ua==Ub
@julian i recognize we are not there yet, but i do think we need to broadly move toward an architecture where a server going down isn’t as catastrophic as it currently is.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login