Option 1 if enabling led is action itself, not side effect.
This would justify having enable/disable specific side effects in those functions. This is unlikely for given example. Enabling/disabling led likely side effect itself. You don’t want to put side effects into side effects.
Option 2 if it’s a side effect of bigger process. Option 2 makes harder to add side effects which will drive (but not guarantee) better separation of concerns.
Though, I’d go with option 1 anyway since I trust my self to not nest side effects even when code doesn’t hint me
User registers at home server. Client generates pair of public and private keys, password provided by user during registration is used to encrypt (symmetrically) private key. Public and encrypted private keys stored on home server and then propagate over federation to other servers. Obviously propagation takes some time. Just like anything that uses ActivityPub (don’t know why I have to say it explicitly). Original private key not recorded anywhere. User initiates login on federated server. Federated server challenges user by providing encrypted private key and challenge phrase. User uses password to decrypt private key on client side and signs message with challenge phrase. Server uses public key to validate signature and phrase. User logged in. User creates signed post. All federated servers have copy of public key so they can check authenticity of origin of post.
I’m not saying it’s easy or perfect. I have no idea how feasible it is in current architecture. Probably there’s a smarter and more secure way to do it. I’m also not a team of security engineers who is getting paid to get this kind of things designed professionally.
My point is that, I think, it’s more of willingness issue than technical.
I won’t pretend I looked into authentication algorithm of every fedi apps but I doubt it’s “trust me bro” algorithm. Otherwise what would prevent malicious instance to post from your name today. Even if it’s some wacky algorithm it’s not a rocket science to enhance it. Message signing and public key sharing is one of common ways to solve this kind of problems. The only reason I see not to do it is lack of will or resources, or both
It’s possible with OpenID. All you need is extract domain from login id and get provider configuration at https:///.well-known/openid-configuration. Problem is that if it’s down you can’t login into same account using another provider.
Technically same way as google or apple SSO works just fixed list of domains. Another problem with using whatever domain user supplied is that some domains are more trusted than others, or rather owners. I don’t mean from privacy perspective I mean stability and security. It’s much easier to hijack domain of small server which struggles to pay for domain name consistently than google.
If Fediverse want to use OpenID for login someone have to vet trusted auth providers.
Otherwise we need someway to federate user logins. Maybe literally have replicated users credentials across instances. Then all federed instances can authenticate users from any federed instance.
Idea of not distributing registrations is dumb. Sounds like they didn’t even tried to find something better. This defeats purpose of federation. Everyone will land on one instance because hashtags don’t federate and people will start moving to big instances.
We don’t need corpo sso. We need federated auth providers and org which can fund instances which want to be on “trusted list”
Wut? You guys have monthly payments for cars? Is this some NA thing? If you really need a a car, just buy used shitbox. There is no flex in being in debt.
31% of webn is tech. It’s a good ride so far but too sketchy to me. There is stoxx 600 which is still gives good ROI, European and has only 8% of tech.
That’s what makes me mad about EU. Seems like they opted for low fine in hope to not trigger tariffs circus, but clown just can’t get over it. They should’ve slapped max fine which would be 40 times bigger
Me, me, me. Only thinking about immediate inconveniences. This why they are where they are. Shoulda think about “building the country and wellbeing of others” in 2014 and 2022. Hell, there were hints in 2008 that their government began to rot.
Wouldn’t same be the case for normal files systems? I think, technically, files on disk stored as flat structure plus tree structure which tracks physical files bytes location on the disk. Is there a file system which actually stores dirs/files data as tree? Adding something into folder would mean moving data of next folder to create “room” for new stuff
Correct answer - depends.
Option 1 if enabling led is action itself, not side effect. This would justify having enable/disable specific side effects in those functions. This is unlikely for given example. Enabling/disabling led likely side effect itself. You don’t want to put side effects into side effects.
Option 2 if it’s a side effect of bigger process. Option 2 makes harder to add side effects which will drive (but not guarantee) better separation of concerns.
Though, I’d go with option 1 anyway since I trust my self to not nest side effects even when code doesn’t hint me
Let’s build some useless statue in the middle of nowhere. What did I expect from millionaire pope anyway, useful infrastructure?
Touching nose with my upper lip
User registers at home server. Client generates pair of public and private keys, password provided by user during registration is used to encrypt (symmetrically) private key. Public and encrypted private keys stored on home server and then propagate over federation to other servers. Obviously propagation takes some time. Just like anything that uses ActivityPub (don’t know why I have to say it explicitly). Original private key not recorded anywhere. User initiates login on federated server. Federated server challenges user by providing encrypted private key and challenge phrase. User uses password to decrypt private key on client side and signs message with challenge phrase. Server uses public key to validate signature and phrase. User logged in. User creates signed post. All federated servers have copy of public key so they can check authenticity of origin of post.
I’m not saying it’s easy or perfect. I have no idea how feasible it is in current architecture. Probably there’s a smarter and more secure way to do it. I’m also not a team of security engineers who is getting paid to get this kind of things designed professionally.
My point is that, I think, it’s more of willingness issue than technical.
I won’t pretend I looked into authentication algorithm of every fedi apps but I doubt it’s “trust me bro” algorithm. Otherwise what would prevent malicious instance to post from your name today. Even if it’s some wacky algorithm it’s not a rocket science to enhance it. Message signing and public key sharing is one of common ways to solve this kind of problems. The only reason I see not to do it is lack of will or resources, or both
Can you explain why exactly? Particular scenario would be helpful to understand your POV
It’s possible with OpenID. All you need is extract domain from login id and get provider configuration at https:///.well-known/openid-configuration. Problem is that if it’s down you can’t login into same account using another provider.
Technically same way as google or apple SSO works just fixed list of domains. Another problem with using whatever domain user supplied is that some domains are more trusted than others, or rather owners. I don’t mean from privacy perspective I mean stability and security. It’s much easier to hijack domain of small server which struggles to pay for domain name consistently than google.
If Fediverse want to use OpenID for login someone have to vet trusted auth providers.
Otherwise we need someway to federate user logins. Maybe literally have replicated users credentials across instances. Then all federed instances can authenticate users from any federed instance.
Idea of not distributing registrations is dumb. Sounds like they didn’t even tried to find something better. This defeats purpose of federation. Everyone will land on one instance because hashtags don’t federate and people will start moving to big instances.
We don’t need corpo sso. We need federated auth providers and org which can fund instances which want to be on “trusted list”
The moment I see GPD as measure I close the article. Means nothing for average Kowalski
Wut? You guys have monthly payments for cars? Is this some NA thing? If you really need a a car, just buy used shitbox. There is no flex in being in debt.
31% of webn is tech. It’s a good ride so far but too sketchy to me. There is stoxx 600 which is still gives good ROI, European and has only 8% of tech.
Don’t think dogs understand hands. They have only legs
That’s what makes me mad about EU. Seems like they opted for low fine in hope to not trigger tariffs circus, but clown just can’t get over it. They should’ve slapped max fine which would be 40 times bigger
TLDR: a lot of text to say that maybe you have a bug because you forgot ordering and idempotence. Check your code.
Has nothing to do with retry in particular btw.
I really doubt Zelensky has full power over all decisions. Military and agencies can be really rooted into the system
None, they only go 322 km/h
You can have both. Just not in one MR. Do what is needed, push, branch off, do what is nice
Me, me, me. Only thinking about immediate inconveniences. This why they are where they are. Shoulda think about “building the country and wellbeing of others” in 2014 and 2022. Hell, there were hints in 2008 that their government began to rot.
Wouldn’t same be the case for normal files systems? I think, technically, files on disk stored as flat structure plus tree structure which tracks physical files bytes location on the disk. Is there a file system which actually stores dirs/files data as tree? Adding something into folder would mean moving data of next folder to create “room” for new stuff
Yeah, I don’t see how to transition from office rat to monster slayer or ninja