ion VS gitlab-foss

- For completeness and good scientific practice, also look at solutions beyond Ethereum: https://identity.foundation/ion/

ION decentralized identity (an implementation of the SideTree protocol)

Other uses are extremely limited IMO. Microsoft ION, an implementation of decentralised identity w3c spec, for example. It makes a Bitcoin transaction containing a hash that refers to several identities. Since the identities are mutable there does not seem much value in remembering the hash at a point in time.

I agree the website is very bad, currently. Maybe this page has better resources:

https://essif-lab.github.io/framework/docs/ssi-standards

But there's quite a lot going on... the work on SSI is being coordinated by the W3C Working Group on VCs (Verifiable Credentials) and DIDs (Decentralized Identifiers).

https://www.w3.org/community/credentials/

https://www.w3.org/2019/did-wg/

I don't know of any real-world usage yet, despite the fact that the specifications required for things to work and be used by real people already exist, and that there's a lot of DID methods (over 80 last I checked) registered, but as people have noted, most are based on blockchain (but not all... there's stuff like the peer, git, jwk DID methods that do not require blockchain)... but I have to say that, in this particular instance, blockchains may actually be a proper solution for a real problem (that of looking up public keys and metadata for entities/users in a distributed, highly-reliable manner).

https://www.w3.org/TR/did-spec-registries/#did-methods

If you want to look for related stuff, look for things that users would need to have to use SSI, like DID wallets... Some random examples I found by quickly searching:

https://www.abtwallet.io/en/

https://www.didwallet.io/

https://igrant.io/

https://www.dock.io/dock-wallet-app

https://identity.foundation/ion/

The OpenID Connect Standard is being extended to support self-issued OIDC (SIOP) which allows OIDC to interact with SSI constructs:

https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...

So, yeah, there's a lot of stuff being created around SSI, but admitedly, almost nothing practical yet... Hence why I was hoping to find something where this work could be very helpful, like logging into Codeberg :)

I would also recommend checking ION¹. I have tested a few DID Methods including Sovrin, Veres One, and ION, and the latter is the most spec-adherent and well-implemented, apart from receiving funding from companies like Microsoft and TBD (which is proposing web5 in the first place). And yes, it is the only DID Method to receive support from big tech (was incubated within Microsoft, then donated to the Decentralized Identity Foundation), and it also happens to be a technically good solution.

¹ https://identity.foundation/ion/

Microsoft ION --->https://identity.foundation/ion/

Doing some more research: Looks like the idea is developed by tbd.website and uses a L2 tool called ION that utilizes the SideTree protocol. Interestingly, ION does not introduce a new token which I find interesting, and one of the things I've found confusing about Stacks.

* Gitlab EE (enterprise edition) is closed, but Gitlab CE (community edition) is open source (https://gitlab.com/gitlab-org/gitlab-foss/)

* I didn't follow the Gitea drama too closely, but my understanding is that Forgejo was a fork born out of that situation

* I've heard the SourceHut guy is a controversial figure, so avoiding it because of that isn't unreasonable. I will just say that "spite forks" tend not to last very long

Gitlab uses an UrlBlocker class to prevent malicious users from exploiting SSRF via the webhook URL. This class validates the URL and blocks everything which is a local network, but before the 11.5.1 version, they didn't think about an IPv6 format, which maps to IPv4: [0:0:0:0:0:ffff:127.0.0.1]. Replacing the part of 127.0.0.1 to any IP address also worked, and this vulnerability made it possible to send requests to the internal network of a GitLab instance. You can read the issue report here: (https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53242 )[https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53242]

I recommend Auto DevOps and hooking your project up to the Kubernetes cluster. Auto DevOps is a standard CI/CD template that GitLab uses by default when .gitlab-ci.yml is not present. It can automatically package up certain types of applications, including those with a Dockerfile in the root of the repo. If the project is hooked up to a Kubernetes cluster and all the right variables are present, it builds that docker image and then fills in a Helm chart template containing that image and deploys it to the cluster.

Thanks. This was also requested for the UI 7 years ago

https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12776

and then closed with the claim that this was implemented, when in fact, it was not.

Similar to fsync, these are designed to ensure data integrity, but in a test setup, they don't matter. You can read more about these in the Postgres doc on non-durability. and explore some benchmarks from Gitlab here. Interestingly, CircleCI's old Postgres images had these features disabled by default, but the newer ones don't seem to.

Most all of those things are possible with Argo Workflows or Tekton with very great effort. But a sustainable system with all the features built-in.

If you wish to clone a copy of GitLab without proprietary code, you can use the read-only mirror of GitLab located at https://gitlab.com/gitlab-org/gitlab-foss/. However, please do not submit any issues and/or merge requests to that project.

GitLab versions 10.7 and later, allow the HTTP(S) protocol for Git clone or fetch requests done by GitLab Runner from CI/CD jobs, even if you select Only SSH.

it sure does