[draft] ICP Dev Docs Restructure, Overhaul & Audit #3970

jessiemongeon1 · 2025-01-22T19:05:28Z

This PR restructures the ICP Dev Docs and makes several significant changes:

Created new documentation categories and top navigation bar sections.
Renamed all documentation files to reflect new categories and sections.
Removed several pages that will be migrated to new ICP Learn Hub website.
Updated and audited all links across all docs pages, internal and external.
If a code example used in the docs was originally sourced from the dfinity/examples repo, the code is now referencing the dfinity/examples repo file through a submodule rather than being duplicated in the documentation page.
Audited every docs page for spelling, grammar, and formatting.
Applied several style guide revisions for consistency in use of hyphens, terminology, capitalization, etc.
Increased Docs Sidebar by 50px to better display long titles.
Fixed bug where single pages rendered as bold text on the sidebar.

github-actions · 2025-01-22T19:54:05Z

🤖 Here's your preview: https://3w7gq-qiaaa-aaaam-abcea-cai.icp0.io

docs/tutorials/developer-journey/level-0/01-ic-overview.mdx

docs/tutorials/developer-journey/level-0/02-ic-terms.mdx

docs/tutorials/developer-journey/level-0/03-dev-env.mdx

docs/tutorials/developer-journey/level-1/1.2-motoko-lvl1.mdx

… into jmongeon-docs-restructure

.github/CODEOWNERS

tmu0 · 2025-01-23T07:34:28Z

docs/developer-education/security/iam.mdx


-Conditions 1, 2 and 3 can be satisfied by convincing the user to initiate an authentication flow with a session public key which is chosen by the attacker by loading the proxy from an attacker controlled mobile or web application. Concretely, an attacker would execute a phishing attack where a victim is directed to the proxy from an unsuspicious application. For example, the victim is convinced that the attacker is issuing an airdrop. The victim has to download a corresponding malicious mobile app that requires II authentication. This malicious mobile app would load the proxy (step 3) similarly to how the legitimate mobile app would. The malicious app would ask the proxy to authenticate the user for an attacker chosen session key. The victim might not realize they are completing an authorization flow for a different dapp origin. Condition 2 is met for any dapp that exposes such an open II authentication proxy on their domain.
+Conditions 1, 2, and 3 can be satisfied by convincing the user to initiate an authentication flow with a session public key that is chosen by the attacker by loading the proxy from an attacker-controlled mobile or web application. Concretely, an attacker would execute a phishing attack where a victim is directed to the proxy from an unsuspicious application. For example, the victim is convinced that the attacker is issuing an airdrop. The victim has to download a corresponding malicious mobile app that requires II authentication. This malicious mobile app would load the proxy (step 3) similarly to how the legitimate mobile app would. The malicious app would ask the proxy to authenticate the user for an Condition 2 is met for any dapp that exposes such an open II authentication proxy on their domain. session key. The victim might not realize they are completing an authorization flow for a different dapp origin. Condition 2 is met for any dapp that exposes such an open II authentication proxy on their domain.


Condition 2 is met for any dapp that exposes such an open II authentication proxy on their domain. duplicated

tmu0 · 2025-01-23T07:51:10Z

docs/developer-education/message-execution/ingress-messages.mdx

-This page discusses ICP's ingress message APIs. While these APIs are defined in detail within the [HTTPS interface specification](/docs/current/references/ic-interface-spec#http-interface), this page provides a more high-level and intuitive overview, with a special focus on error handling. That aspect is particularly important, as it can be tricky to determine if an ingress message has actually been successfully executed. Misinterpreting errors could lead to bugs such as double spending.
+See also the introductory [call overview](/docs/current/building-dapps/calling-dapps/query-calls) to learn more about calling canisters.
+
+This page discusses ICP's ingress message APIs. While these APIs are defined in detail within the [HTTPS interface specification](/docs/current/references/ic-interface-spec#http-interface), this page provides a more high-level and intuitive  with a special focus on error handling. That aspect is particularly important, as it can be tricky to determine if an ingress message has actually been successfully executed. Misinterpreting errors could lead to bugs such as double spending.


high-level and intuitive overview

docs/building-dapps/dapp-frontends/asset-certification.mdx

docs/building-dapps/dapp-frontends/existing-frontend.mdx

jessiemongeon1 added 17 commits January 6, 2025 13:27

init

259edcc

building dapps

9c04ea1

rosetta

6451290

references

0d1aeb9

references

0b5d9db

Finish redirects and link updates

10bbe23

content revisions

e4e2034

audit dev education, getting started, dev tools sections

d7c4e57

interacting, launching, managing dapps

3243e2b

network features and chain fusion

79ff84c

sns, tokens, rosetta

e773c79

tutorials

7a9151c

references

f61808d

Check all links; add dev education pages

b7cee04

link checks, applying feedback, formatting

96b0a85

link checks, applying feedback, formatting

f32f788

finish link checks and format fixes

e89582d

jessiemongeon1 requested review from a team as code owners January 22, 2025 19:05

merge conflicts

dff3ecb

github-actions bot added the documentation Changes to Developer Docs label Jan 22, 2025