Update examples to use latest linera-web APIs.

[deuszx]

Updates the examples (and extension) to use the latest API from linera-protocol/linera-web.

A new example integration - called hosted-counter-metamask - was added which uses MetamaskSigner.

Faucet URL and app IDs are now provided via env variables (see .env file).

Closes #51

Below the recording of integration w/ MetaMask

Screen.Recording.2025-06-11.at.17.48.02.mov

[Twey]

Nit: I think it would be better to use this qualified as signer.PrivateKey. Otherwise it's not necessarily clear to the reader that this is a private-key signer and not just a private key.

[Twey]

(I guess it was imported unqualified because the module name used to be suffixed to the class name as well, but that's no longer the case)

[deuszx]

I thought signer.PrivateKey is unnecessary and files are small enough to easily see where the import comes from.

[deuszx]

(I guess it was imported unqualified because the module name used to be suffixed to the class name as well, but that's no longer the case)

Exactly :)

[Twey]

I kind of agree, which is why it's a nit, but for people encountering this API for the first time it might be best to be super explicit.

[deuszx]

That's why I wanted to call this PrivateKeySigner - to avoid confusion like this :)

[Twey]

I've written this before but — the reason modules are nice to have as a language construct is that the information that is obvious about a name changes depending on the context. Back in the good old days of C we would always have to write struct linera_signer_private_key everywhere because there weren't any kind of modules to put things in. That's usually sufficiently informative, but in a lot of cases you want to do something a bit different:

• inside the Linera codebase (or a Linera-specific module in an external codebase) it's pretty obvious that you're talking about Linera things, so calling it a ‘Linera private key signer’ (LineraPrivateKeySigner) isn't necessary, and it's enough to refer to it as a ‘private key signer’ (signer.PrivateKey);
• inside a ‘signer’ module (e.g. abstraction layer) of some external project it might not be obvious that this thing is specific to Linera but it is obvious that it's a signer, so you want to refer to it as a ‘Linera private key’ (linera.PrivateKey);
• inside a ‘Linera signer’ module there's no need for any of this information (everything here is a Linera signer, or helpers for one) and the only thing you care about is that it is a private key signer (PrivateKey);
• bit of a contrived example for this one in particular (because ‘private key’ is jargon usually specific to crypto), but inside a very high-level context about generic authentication mechanisms you might have a mechanism that's about actual physical signatures made with a pen on paper! So you might want to disambiguate that by referring to this as the Linera crypto signer (signer.crypto.linera.PrivateKey).

When you try to include all possible context into the base name, you're cursing your users to always include all of that context, even when it's not relevant, and to not be able to decide (or at least be strongly discouraged from deciding) what information is relevant to them. Conversely, you're taking on the burden of trying to guess all the possible contexts that the name could appear in and creating a name that's suitably unambiguous in every single one. Using the language's module facilities, on the other hand, means consumers (including you, the producer!) can adapt the name in different contexts to omit the information that's obvious and keep or add information that's pertinent.

The fact that the word ‘signer’ is pertinent in this context doesn't mean it's pertinent in all contexts such that it should be made part of the core name. In fact, a great example of a context in which it's not pertinent at all (because it's super obvious) is the module where it's defined, linera_base::crypto::signer.