ongy

I tried to find something definitive, but it would take more time than I have right now. So to some degree this is assumptions, though generalized.

* Does the site know who the user is: No. That's the entire purpose here.

* Does the site know who the attestor is: Yes, they need to validate asymmetric crypto on the proof, so they need a list of public keys (which they can attach attestor identity to).

* Does the attestor know what kind of content I want to visit: They should not. With the JWT you can validate without telling the attestor which user's proof you validate. OTOH, if there's some "is this one revoked" type of API one could easily re-introduce such an information channel on accident.

* does the attestor know who the user is: Yes (or at least have some bits of information about you they are willing to attest to others. In practice assume it's Google/Apple/MS with information associated with your account, or your bank or ...)

* Does the user always know site/attestor: From a technical perspective yes. From a practical human one... doubtful.

--Googler, though far removed from this project, so no internal knowledge.

Gotta admit, I was expecting some hiring/Social biases topic.

This was quite interesting though. Surprised to see it work so well on a real example.

I have the Framework 12".

It's hard to justify the price unless you put value to Framework's gimmicks and mission.

There's no illusion that I'm not paying extra to vote with my wallet for sustainability. And I'm on with that.

In my university times I wrote a library (to help with some homework we gave students) that calculated the CRC32 for ethernet.

Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled...

Just writing UDP RFC compliant code doesn't protect you from running into annoying behavior with your programming language of choice...

I think you are talking about colocation, which is slightly different than the `jj git push` `jj git fetch` type commands.

Colocation has its uses bit is a bit finicky. The push/pull compatibility works perfectly fine (with some caveats of github being broken that can be worked around).

It's the third attempt of building the mono repo.

But not the 3rd mono repo on the same technology to avoid some scaling limit.

Crypto wise, fips is outdated but not horrible.

Actual fips compliant (certified) gives you confidence in some basic competence of the solution.

Just fips compatible (i.e. picking algos that could be fips compliant) is generally neutral to negative.

I'm not 100% up to date, so that might have changed, but AEAD used to be easier if you don't follow fips than fips compatible. Still possible, but more foot guns due to regulatory lag in techniques.

Overall, IMO the other top-level comment of "only fips if you have pencil pusher benefit" applies.

I'm aware. I'm worried we'll get an Aussie customer at work and I have to fix their access to our systems...

Granted, we already have US/EU/Asia as distinct regions. AUS would just make fail over even worse.

Smack center of Europe (southern Germany) Got >100ms pings.

I love fastmail, but I really wish they had servers close to me.

The high ping kills the throughput on davfs and makes their website hosting a pain to update :(

Your pseudo XML seems quite broken, since the supposed git style doesn't close the parent at all.

But the git directory entry contains: * a type (this one is quite limited, so I'm not sure how well that could be (ab)used * a name * a pointer to the content

Which is exaclty what an AST entry has.

the git server would continue to work.

The cli really isn't the greatest either way. But there's lots of infrastructure to make the sharing work reasonably well.

An AST is a tree as much as the directory structure currently encoded in git.

It shouldn't be hard to build a bijective mapping between a file system and AST.

Why do you think it has too many children? If we are talking direct descendents, I have seen way larger directories in file systems (git managed) than I've ever seen in an AST.

I don't think there's a limit in git. The structure might be a bit deep for git and thus some things might be unoptimized, but the shape is the same.

Tree.

That black hole behavior is a result of corporate processes though.

Not a result of git.

Business continuity (no uncontrolled external dependencies) and corporate security teams wanting to be able to scan everything. Also wanting to update everyone's dependencies when they backport something.

Once you got those requirements, most of the benefits of multi-repo / roundtripping over releases just don't hold anymore.

The entanglement can be stronger, but if teams build clean APIs it's no harder than removing it from a cluster of individual repositories. That might be a pretty load bearing if though.

What issues do you see in git's data model to abandon it as wire format for syncing?

Which either allows to use a fingerprint of the signing key to be used for the same.

Or would open the system up to the originally posted attack of providing ~an open relay.

Ahh. The not-quite-a-hotel. I don't think I ever used them.

How does that prevent the ID service from discovering which services you use it for?

You could do some scheme that hashes a site specific identifier with an identifier on the smart element of the id.

If that ever repeats, the same I'd was used twice. At the same time, the site ID would act as salt to prevent simple matching between services.

Which hotel asks for id online..? I've only ever had to provide it once on-site and checking in.

And when then, only when I'm in foreign countries.

My main issue is trust.

In real world scenarios, I can observe them while they handle my ID. And systematic abuse(e.g. some video that gets stored and shows it clearly) would be a violation taken serious

With online providers it's barely news worthy if they abuse the data they get.

I'm not against age verification (at least not strongly), but I'd want it in a 2 party 0 trust way. I.e. one party signs a jwt like thing only containing one bit, the other validates it without ever contacting the issuer about the specific token.

So one knows the identity, one knows the usage But they are never related

No printer.

Iirc. Jack was accepted by the organizers but pressured out by the community.

Also, about github: Had a chat with the Gitlab chap doing the Git talk in the main track. Apparently they dialed back their involvement with upstream git quite a bit. Github is currently providing a lot of infra gratis (thanks!) but is at best neutral to code and community.

Agreed, this year was a bit light on questions.

OTOH, 80% of the reason I go to talks is to see if the person has interesting things to say and grab them after the talk for a chat. I.e. it sucks for the remote experience, but I think for on-site it's fine to just talk more.

Gets harder if you consider the talks the main attraction, but I really see them more as hooks to talk to people about interesting topics.

Eurostar was fine for me. Getting to the Eurostar within Germany apparently sucked for some. But I took a later train and didn't have issues there either.

It's mainly re-hashed. I think I've seen the same talk twice before? At least once.

It's a very "I've made a cool thing. This is what I think is cool about it" type of talk. Which I don't think is uncommon for FOSDEM. Maybe a bit uncommon for a higher profile figure like Lennart.

The most important realization about FOSDEM is really:

There's no way you can fully experience it or do it optimal.

It's really about making sure you get value out of it, listen to some interesting talks and meet some people.

Which probably also relates to DB pricing.

Being flexible with DB is expensive. Getting somewhere at all is generally cheap. Getting somewhere at a reasonable time is usually ok~ish priced. But being able to just take any train? €€€

Hopefully cartel regulation would prevent Microsoft from using their market leader position to force partners to remove all support for competitors.

But I'm losing hope with those.