Costin Manolache
@costinm.bsky.social
developer - Istio, Android push (C2DM/GCM/FCM), Webpush, Tomcat/Ant and a few other smaller or failed projects. [github.com/costinm]
[@costin.manolache:matrix.org]
[@costin.manolache:matrix.org]
New code is maybe 5% of the job, if you are lucky. Dealing with existing code, policies, requirements and feedback is the hard work. And most of the 'new code' is reusing and wrapping old code.
April 29, 2025 at 8:43 PM
New code is maybe 5% of the job, if you are lucky. Dealing with existing code, policies, requirements and feedback is the hard work. And most of the 'new code' is reusing and wrapping old code.
It works in most cases - but you'll need to poll AFAIK - unless you use some trigger that notifies on insert.
March 14, 2025 at 9:23 PM
It works in most cases - but you'll need to poll AFAIK - unless you use some trigger that notifies on insert.
Pretty sure 'requiring a search engine to do anything on the web' is not part of the Web design, and bookmarks also work to find web sites you need.
February 20, 2025 at 12:29 AM
Pretty sure 'requiring a search engine to do anything on the web' is not part of the Web design, and bookmarks also work to find web sites you need.
To be fair - most web pages and new sites have about the same accuracy, just harder to read. Just a human giving impression of accuracy.
February 17, 2025 at 11:53 PM
To be fair - most web pages and new sites have about the same accuracy, just harder to read. Just a human giving impression of accuracy.
Long ago I actually worked on this kind of migrations, I wouldn't say that part was a success in making it simple but lots of domains manage to do it, including registrar and DNS. Migrations are a pain but routine: interoperable standards with many impl are key.
February 10, 2025 at 5:36 AM
Long ago I actually worked on this kind of migrations, I wouldn't say that part was a success in making it simple but lots of domains manage to do it, including registrar and DNS. Migrations are a pain but routine: interoperable standards with many impl are key.
Few MX/CNAME changes to move mail or web hosting to a different provider. Same for identity (if you own the domain). Migrating the content is more work.
A server can also allow multiple IDPs and identities as 'aliases' to access the same account. Identity federation is pretty standard.
A server can also allow multiple IDPs and identities as 'aliases' to access the same account. Identity federation is pretty standard.
February 10, 2025 at 5:27 AM
Few MX/CNAME changes to move mail or web hosting to a different provider. Same for identity (if you own the domain). Migrating the content is more work.
A server can also allow multiple IDPs and identities as 'aliases' to access the same account. Identity federation is pretty standard.
A server can also allow multiple IDPs and identities as 'aliases' to access the same account. Identity federation is pretty standard.
Oauth dance to login to the appview/UI. Get JWTs. Use them to make calls to the PDS. Configure PDS to accept specific IDP and identity for a user (handle). Or just add your IDP identity in the DID, as alternate identity (if you are ok with the privacy implications - otherwise the link is private).
February 10, 2025 at 5:17 AM
Oauth dance to login to the appview/UI. Get JWTs. Use them to make calls to the PDS. Configure PDS to accept specific IDP and identity for a user (handle). Or just add your IDP identity in the DID, as alternate identity (if you are ok with the privacy implications - otherwise the link is private).
Links ? Would love to use one without password.
February 10, 2025 at 1:10 AM
Links ? Would love to use one without password.
Neither did HTTP proto - and it didn't work so well, which is why many sites no longer use passwords.
Secret storage (private keys too) is tricky and assuming passwords are 'implementation detail' and 'this time they'll work' - or PDS servers are as secure as a real IDP is risky.
Secret storage (private keys too) is tricky and assuming passwords are 'implementation detail' and 'this time they'll work' - or PDS servers are as secure as a real IDP is risky.
February 10, 2025 at 1:09 AM
Neither did HTTP proto - and it didn't work so well, which is why many sites no longer use passwords.
Secret storage (private keys too) is tricky and assuming passwords are 'implementation detail' and 'this time they'll work' - or PDS servers are as secure as a real IDP is risky.
Secret storage (private keys too) is tricky and assuming passwords are 'implementation detail' and 'this time they'll work' - or PDS servers are as secure as a real IDP is risky.
Yes, supporting OIDC JWTs or OAuth on a custom PDS is pretty easy. I don't think the current UI on Bsky will work with it.
February 10, 2025 at 12:54 AM
Yes, supporting OIDC JWTs or OAuth on a custom PDS is pretty easy. I don't think the current UI on Bsky will work with it.
Why ? How does the PDS store and handles the passwords ? 2 factor, recovery and all the goodies a real IDP has ? I don't mind running a PDS for storing social data ( or trusting BSky or others to run it ) - but I would rather keep identity in a separate and more secure/standard place.
February 10, 2025 at 12:52 AM
Why ? How does the PDS store and handles the passwords ? 2 factor, recovery and all the goodies a real IDP has ? I don't mind running a PDS for storing social data ( or trusting BSky or others to run it ) - but I would rather keep identity in a separate and more secure/standard place.
PDS is a pretty non-standard identity provider that you are forced to use in context of ATproto because auth is locked-in.
Gmail, Github, Facebook, etc are THE identity providers most people use, and the OAuth protocol is designed for federation, not for PDS to be the only possible IDp.
Gmail, Github, Facebook, etc are THE identity providers most people use, and the OAuth protocol is designed for federation, not for PDS to be the only possible IDp.
February 10, 2025 at 12:42 AM
PDS is a pretty non-standard identity provider that you are forced to use in context of ATproto because auth is locked-in.
Gmail, Github, Facebook, etc are THE identity providers most people use, and the OAuth protocol is designed for federation, not for PDS to be the only possible IDp.
Gmail, Github, Facebook, etc are THE identity providers most people use, and the OAuth protocol is designed for federation, not for PDS to be the only possible IDp.
Or even better - support the identity providers most people commonly use, and allow them to configure their own custom ones if they want.
Last thing I want is to use Bsky as an identity provider and have to use a password in 2025.
Last thing I want is to use Bsky as an identity provider and have to use a password in 2025.
February 10, 2025 at 12:40 AM
Or even better - support the identity providers most people commonly use, and allow them to configure their own custom ones if they want.
Last thing I want is to use Bsky as an identity provider and have to use a password in 2025.
Last thing I want is to use Bsky as an identity provider and have to use a password in 2025.
You need the real OAuth - where users can use their own identity provider - and no longer need passwords. The purpose of the protocol was to allow identity federation, not lock in. Support OIDC JWTs - no need for apikeys.
February 10, 2025 at 12:36 AM
You need the real OAuth - where users can use their own identity provider - and no longer need passwords. The purpose of the protocol was to allow identity federation, not lock in. Support OIDC JWTs - no need for apikeys.
Just like following suggestions from internet pages with outdated content, except you can ask follow up questions. Even suggestions from 'experts' can give infuriating and wrong suggestions, in particular when they are trying to sell you some complicated solution.
February 1, 2025 at 1:40 AM
Just like following suggestions from internet pages with outdated content, except you can ask follow up questions. Even suggestions from 'experts' can give infuriating and wrong suggestions, in particular when they are trying to sell you some complicated solution.
What k8s ( vendor, self managed), and how 'long' ( days, weeks, years ?). It doesn't randomly delete pods. Affinity, priorities, disruption budget are common - configuring cluster upgrade depends on vendor.
January 27, 2025 at 1:29 AM
What k8s ( vendor, self managed), and how 'long' ( days, weeks, years ?). It doesn't randomly delete pods. Affinity, priorities, disruption budget are common - configuring cluster upgrade depends on vendor.
Or that Moe should have my email and sell it or spam me...
January 24, 2025 at 7:25 PM
Or that Moe should have my email and sell it or spam me...
Grant, subject/principal are pretty confusing and mostly used to sound fancy and secure IMO. It's the address where you authorize someone to use your identity.
January 18, 2025 at 8:16 PM
Grant, subject/principal are pretty confusing and mostly used to sound fancy and secure IMO. It's the address where you authorize someone to use your identity.
I use open-webui, localai is nice too - in docker.
I have solar panels, no coal used running my local LLM ( seems to be the biggest problem for many people)
I have solar panels, no coal used running my local LLM ( seems to be the biggest problem for many people)
January 17, 2025 at 9:04 PM
I use open-webui, localai is nice too - in docker.
I have solar panels, no coal used running my local LLM ( seems to be the biggest problem for many people)
I have solar panels, no coal used running my local LLM ( seems to be the biggest problem for many people)