data(providers): fill 40 missing link cells for 28 providers (batch 1 of 4)

[EazyHood]

Summary

Fills 40 empty cells across 28 providers in references/providers/providers.csv (1rpc … forge). No rows added or removed, and no cell that already had a value was changed.

column	cells filled
github	8
docs	7
x	13
discord	7
telegram	5

One of four batches (#3323, #3324, #3325, #3326) covering different providers; no cell appears in more than one of them. Rebased on current main — the earlier version conflicted after #3211, #3218, #2814 and #3309 touched this file, which is also why no workflow ran on it (GitHub does not trigger pull_request workflows on a conflicting PR).

Type of change

• Add data rows
• Update data rows
• Remove data rows
• Schema change
• Documentation/metadata only

Scope

• Networks affected: global (provider identities, not listings)

• Categories affected: references/providers

• Additional notes, additional context / screenshots:

Overlap with #3250, stated up front. #3250 fills 450 provider cells and 15 of the cells in this PR are also in it — with the same value in every case; where the two disagreed, the cell was removed from here. Whichever lands second rebases and those cells become a no-op in it, so nothing is claimed twice. They are kept here because #3250 is large and has been cycling on link-check noise since 27 August, and these batches are small enough to clear a review cycle on their own.

Where the values come from. Two first-party sources, never a guess from the slug: the provider's own website (outbound links and twitter:site meta tag), and the provider's own GitHub organisation profile (twitter_username), plus the provider's own docs./developers. subdomain accepted only when the URL after redirects stays on the provider's registrable domain. A value was written only when unambiguous; where two plausible candidates existed, the cell was left empty. That is why these four PRs fill ~160 cells and not the ~650 that are empty.

Accuracy, measured before writing anything, by running the same extraction against providers whose value is already recorded:

github  64/67   agree   95.5%
x      114/117  agree   97.4%   (from the provider's site)
x      171/175  agree   97.7%   (from the GitHub org profile, after a name-similarity filter)

A third source was measured and rejected: the GitHub profile's blog field agrees with the recorded website only 80.7% of the time, so no website cell is touched.

Link checking. Every link in every touched row — the cells added here and the website/docs values already present in those rows — was requested with TLS verification on and compared against the accept list this repo's link-check uses (200,202,204,400,401,403,405,429): across the four batches, 523 links, 0 failures. Three rows that could have been filled were left out because they carry a link that was already in the database and fails today (swing: expired certificate and a docs domain that no longer resolves; polyzoa: 404; learnweb3: 503) — since the check reads whole rows, touching them reports those failures against this PR. No linkedin cell is included, for the reason in #3347.

Changed since the first review on this PR: core-dao's x was name — Core DAO's own page carries <meta name="twitter:site" content="@name">, an unfilled template value that my extractor took at face value. It is now Coredao_Org, which is what the same page links to and which returns 200.

Style Guide conformance. docs as a full quoted URL; x, github, discord, telegram as value-after-domain only; discord as the bare invite code, matching 125 of the 136 existing values. Row order untouched, so the file stays A–Z by slug.

Links

• Related issue(s) / DB Improvement Proposal: none — data population, no schema change. See [DBIP] The link check cannot validate the x and linkedin columns: 60% of its errors are X and LinkedIn refusing CI, not broken links #3347 for why linkedin is excluded.

Validation checklist

• I followed the Style Guide and Column Definitions. I'm aware of what is !provider syntax, and that entities in /networks sub-folders inherits records from /providers folder
• I personally opened and verified every new link I'm adding. I can confirm, that all the links I'm adding are valid.
  • To be exact about what "verified" means here: every link was checked with an HTTP request as described above, not opened one by one in a browser. Every value in this PR returned an accepted status; everything that did not was removed before submitting.
• If I added new entries - I personally confirmed that the provider I'm adding (modifying) currently supports the adjusted network(s). I've also verified that value in every cell I'm changing is correct according to my best understanding
• This PR is not a blind AI-generated submission

Optional

• Rewards address (for data patching rewards): 0x06f44f4839fd5df4f4670036d028b29dec939363
• Twitter (X) post link (for +10% of rewards to this PR): https://x.com/del_mejia95726/status/2095272702319743473

[github-actions]

Summary

Status	Count
🔍 Total	195
🔗 Unique	195
✅ Successful	194
⏳ Timeouts	0
🔀 Redirected	31
👻 Excluded	0
❓ Unknown	0
🚫 Errors	1
⛔ Unsupported	0

Errors per input

Errors in ./references/providers/providers.csv

• [999] https://www.linkedin.com/company/base-l2 (at 82:1) | Rejected status code: 999 Unknown status code

Full Github Actions output

[USS-Supervisor]

Verdict: REQUEST_CHANGES
Risk: MEDIUM
Summary: The provider CSV remains structurally valid, but one newly filled provider social field is unsupported by the provider's own site.
Findings: MEDIUM - references/providers/providers.csv, row core-dao, field x: the PR sets the X handle to name, which appears to be leaked metadata rather than Core DAO's official X account. Core DAO's own website links to twitter.com/Coredao_Org. Please replace this with Coredao_Org or leave the field blank if you cannot confirm the official handle.
Confidence: HIGH

Required validation passed. Current-cycle link-check run 33375666339 completed with workflow success but its report still showed 1 URL error, so this review cannot approve the PR in this cycle.

[EazyHood]

One thing worth flagging before the link-check runs on this, because it is likely to report x.com URLs as errors and they will not be broken links.

X throttles GitHub-hosted runners. In the most recent link-check run on #2977 — 2663 links checked — 25 of the 42 errors were on x.com or linkedin.com, including:

[ERROR] <https://x.com/stripe>
[ERROR] <https://x.com/SuiNetwork>
[ERROR] <https://x.com/ton_blockchain>

Those accounts are live; all three return 200 from an ordinary connection. The same handle comes back as ERROR, 404 or 500 between runs depending on throttling, which is why #2977, #2978 and #2979 have been cycling on this since 16 August.

I have already removed every linkedin value from these four PRs for that reason — 40 cells I had verified — and opened #3347 proposing a configuration fix.

For the x values that remain here: each one was taken from the provider's own website or its GitHub organisation profile, and each returned 200 on x.com at submission time. I have not removed them because they are correct and because doing so would leave the column permanently unfillable. If the check flags a specific handle in this PR, say which one and I will drop that cell in the same hour — I would just rather not delete 75 verified values pre-emptively against an intermittent signal.

Everything else in these rows was re-checked against your accept list (200,202,204,400,401,403,405,429): 523 links across the four batches, 0 failures.

[EazyHood]

On the core-dao finding: you are right, and the cause is worth a line. Core DAO's own page ships <meta name="twitter:site" content="@name"> — a Next.js template value nobody filled in — and my extractor took the meta tag at face value. The same page links twitter.com/Coredao_Org, which is what the cell now holds; it returns 200.

While fixing that I rebased all four batches on current main (the earlier heads had conflicted after #3211, #3218, #2814 and #3309, which is also why no workflow ran on them), removed the swing, polyzoa and learnweb3 rows whose pre-existing links fail the check, removed every linkedin cell (#3347), and removed 15 cells where #3250 fills the same cell with a different value so the two cannot contradict each other. Details are in the updated description.