#doauth — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #doauth, aggregated by home.social.
-
Posted a couple of little videos: "The Code of Escape": https://tubedu.org/w/cUVPfyAKNyBCLXRT8rps7m where we learn the least stupid way to set terminal titles.
And "HTTP Client in JavaScript": https://tubedu.org/w/vHgkBkJmTDExVFKkF9BQMY where I demonstrate how to make a #doauth registration form from scratch while making a minimal wrapper around fetch API in order to write denser code.
If you like my bits, subscribe with RSS to my tubedu channel! https://tubedu.org/feeds/videos.xml?videoChannelId=72
-
Going live again! Come watch #doauth <~> #arclight integration gets tighter https://behold.memorici.de
-
Going live with ambient sounds (outdoor cafe[1] + cyberboard typing[2]).
Main goal for today is adding a #doauth authentication to #duex (an #elixir file upload demo with upload capabilities as rich as Google Drive's, i.e. multi-file upload and *directory* upload!).
Secondary: start closing UX tickets related to accounting (as in AAA) from #megalith for #zerohr.
Tune in! https://behold.memorici.de
--
[1]: https://www.youtube.com/watch?v=Xxs5X8RYCxE
[2]: https://www.youtube.com/watch?v=OQpWL_dEJm0 -
Dropping #ecto in favour of using a #genserver with a simple async persistence only for the things that need to be persisted made a credential verification from a 50+ms ordeal into 1-ms ordeal. x50 speedup makes me hopeful about #doauth 0.4 demo making a user account in sub-100ms, compared to sub 1.5s which 0.3 shows.
-
https://github.com/doma-engineering/cluster/tree/main/lib/uptight
Making #elixir reasonable with deep functional programming.
If I had Uptight.{Text, Binary, Base} while coding #doauth v0.2 and 0.3, I would have done it so much faster.
-
I know this demo is kinda trashy, but it's a good introduction into how a "registration" works with #doauth and #verifiablecredentials.
https://www.youtube.com/watch?v=22zbm2qNhSw
If you have any feature requests for a next-gen federated authentication and authorisation system, hit me up or make an issue: https://github.com/doma-engineering/do-auth/issues
You can also contribute stuff like biometrics support via react-native (to eliminate the password) and more fun protocols! We also need replication via federation for high availability.
If anyone is excited about #AAA system that anyone can set up in under half an hour (as opposed to #keycloak) and that uses VC/DID by default, and doesn't use blockchain to store data, let's chat too!
-
Day job done for today, it means, it's time to write some code for #doauth. Tune in to my no comments stream. I reply in chat though.
-
Reimplementing trust on first use for #doauth over at https://twitch.tv/0x101
-
With the tech I have developed with #doauth, I figured, it would make sense to build something like a FOSS about.me that is geared towards geeks, with a cup-of-coffe-per-month hosting.
What key features would you like to see in such a product?
Boosts are welcome.
-
```
Wed Jun 16 16:22:06:471171601 sweater@rethink ~
λ pass doma/maja.doma.dev
"slip": {
"ops": 4,
"mem": 40960,
"saltSize": 16,
"salt": "5A7ZuPZv8yrOdbU0CTZ0mQ=="
}*redacted*
```Feels great to have #doauth password and KDF slip stored in my password manager!
Sneak peek:
-
One step closer to integrating #doauth and #mastodon!
As of today we have browser-issued #verifiablecredentials.
-
I made so many accounts with #doauth already, omg.
-
You can already deploy #doauth to your server in dev mode and start registering users. If you do, share your server's PK with me so that I can add it to my server!
https://git.sr.ht/~doma/do-auth/commit/d6703343e9c437a51a1133335d5fd421126818cb
-
Working hard on #doauth being privacy-preserving. API first, backend later.
-
-
Managed to write a count-based invite system full implementation with #doauth as a library takes 111 LoC.
Going to write tests tomorrow and start looking into integration with mastodon 🎉
-
Another milestone for #doauth!
Invite functionality is implemented, now it's basically #clubhouse.
-
Getting sleepy...
I wonder if I'll manage to implement limked lists for verifiable credentials as seen in #doauth, thus implementing everything needed for the quantity-bound invite protocol.
-
Another milestone in #doauth's history: JS client verified its first credential!
-
We are getting places with #doauth cryptography in browser.
Can't wait to polish the second prototype and start integrating it with services, looking at OIDC compliance, etc. -
Finally, #doauth is sending stuff over HTTP!
A pretty big day.
-
With #doauth. it's really easy to make and validate claims, embedded into #verifiablecredentials
We're trying to prioritise #UX for people who want to use our software (as well as, when the time shall come to make frontends, #UX for the end users).
-
Good morning! Time to fix some #doauth tests I broke while implementing tofu logic.
-
-
Been a while since I've updated y'all about #doauth.
Well, we can insert credentials under transaction with a very nice interface: a keypair and a claim map.
Underneath, it's 99%-compliant with #verifiablecredentials and #decentralizedidentifiers standards, but on the surface it just gives programmers what they care about!
Here's how to insert a credential / claim in #doauth: https://git.sr.ht/~doma/do-auth/commit/d2a28de2e48dfd3c739b40633b280c4ab4814826#test/db_test.exs-1-4
-
Today #doauth has verified its first credential.
Going to clean up noisy logging output and push the code tomorrow.
-
Today #doauth has issued its first credential in testing...
Big things are coming!
-
-
On the subject of re-writing the same thing over and over again.
For #doauth I need to capture detached signatures[1] in #API.
I made a `:> Capture ` query on #hackagesearch website[2] and after very very brief exploration, an API capturing something called `SessionToken`[3] caught my eye.
Upon inspection it turned out that they have B64 encoding as well, except significantly less deranged than mine.
[1]: https://hackage-search.serokell.io/?q=%3A%3E+Capture+
[2]: https://hackage-search.serokell.io/viewfile/battleplace-0.1.0.10/BattlePlace/WebApi.hs#line-44 -
#mastodon is very stable in terms of memory consumption!
But I'm thinking about what we're really doing here in #fediverse and I'm comparing it with, let's say, resource footprint of #circumlunar community (Zaibatsu / ... / Soviet) and realise that their footprint is kind of zero.
Everyone is on one of the three manually federated servers, using UNIX / pre-UNIX tools to communicate with each other, with the only non-UNIX tool being IRC.
Somehow it doesn't take 2GiB of memory and somewhat constant CPU load for #sundogs to exchange bytes.
I get that to host huge instances like mastodon.social, it makes sense to have #pgsql, but it feels like individual instances should be able to be cohosted on the same machine.
I'm committed to explore using file system and files for #doauth persistent storage backend.
But that also brings me to a dilemma of whether or not to use #elixir for the rewrite or to use #rust, to decrease footprint.
Obviously, #elixir will yield more stable, fault tolerant code with easier replication. #Rust, however will reduce excess footprints to 0 at a cost of longer development time (I'll need to benchmark current #tokio-based HTTP servers and see if I need to write my own dead simple server that doesn't use generics / isn't bloated), and it can easily eat up a month of my time.
Maybe it's all non-issue, especially if there's just one BEAM machine launched per host and we plug our applications into it (as intended)...
I think that the fact that I'm heavily leaning towards #elixir as the main production technology even though "close-to-metal" argument is important to me is a clear sign I should use it for production in #doma.
-
#mastodon is very stable in terms of memory consumption!
But I'm thinking about what we're really doing here in #fediverse and I'm comparing it with, let's say, resource footprint of #circumlunar community (Zaibatsu / ... / Soviet) and realise that their footprint is kind of zero.
Everyone is on one of the three manually federated servers, using UNIX / pre-UNIX tools to communicate with each other, with the only non-UNIX tool being IRC.
Somehow it doesn't take 2GiB of memory and somewhat constant CPU load for #sundogs to exchange bytes.
I get that to host huge instances like mastodon.social, it makes sense to have #pgsql, but it feels like individual instances should be able to be cohosted on the same machine.
I'm committed to explore using file system and files for #doauth persistent storage backend.
But that also brings me to a dilemma of whether or not to use #elixir for the rewrite or to use #rust, to decrease footprint.
Obviously, #elixir will yield more stable, fault tolerant code with easier replication. #Rust, however will reduce excess footprints to 0 at a cost of longer development time (I'll need to benchmark current #tokio-based HTTP servers and see if I need to write my own dead simple server that doesn't use generics / isn't bloated), and it can easily eat up a month of my time.
Maybe it's all non-issue, especially if there's just one BEAM machine launched per host and we plug our applications into it (as intended)...
I think that the fact that I'm heavily leaning towards #elixir as the main production technology even though "close-to-metal" argument is important to me is a clear sign I should use it for production in #doma.
-
@markosaric @plausible good job y'all! Rooting for you heavily.
I hope that the interview on Serokell's blog that Gints and I prepared questions for contributed even a little bit ;)
With #doauth, and in general, all that I plan for #doma, I'm looking for a similar model.
Would be cool to sit down and chat about the strategy and tools to launch ethical software business some time in early Q2 '21.
Also, have you considered making a podcast or somesuch about your journey with @plausible and ethical software? I'm pretty sure a lot of people would tune in.