On Wed, 21 Aug 2024 at 14:01, Alix Brunet <alixbrunetcontact@gmail.com> wrote:
>
> Is there a way to have 2FA backup codes?

Not in the way which you expect.

But without trying to sound snarky: Just backup your TOTP secret.

On Sat, 11 Feb 2023 at 22:03, David Florness <david@florness.com> wrote:
> Is it possible to use OAuth 2.0 client tokens for sourcehut services
> (git.sr.ht, todo.sr.ht, lists.sr.ht, etc)?

For git.sr.ht it is definitely possible. And since the authentication
and verification of the tokens depends on the meta service, I don't
see why the other two services would be any different.

> Provided that OAuth2.0 is supported, would a patch to update the
> config.example.ini files be accepted?

While I have no authority to give a definite answer, I don't see any
reason why such a patch would not be accepted. But /oauth also links
to /oauth2 and apart from those links I don't see what you would want

On Mon, 9 Jan 2023 at 17:41, Lionel Dricot - Ploum <lio@ploum.be> wrote:
>
> It should be highlighted that "carbon-neutral" is often used as a pure
> marketing greenwashing gimmick.
>
> If by "carbon-neutral", you mean "buying carbon offset", there’s a very
> high chance that this means mostly bullshit.

There is a recent article by The Guardian, reinforcing this:
https://www.theguardian.com/environment/2023/jan/18/revealed-forest-carbon-offsets-biggest-provider-worthless-verra-aoe

In plain text mode, Gmail wraps messages
at 78 characters when sending them.
---
 es/index.html | 2 +-
 index.html    | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/es/index.html b/es/index.html
index 8d72aec..4429800 100644
--- a/es/index.html
+++ b/es/index.html
@@ -250,7 +250,7 @@
     <h3 id="gmail-web">Gmail</h3>
     <div class="breakdown">
[message trimmed]

On Tue, 19 Oct 2021 at 23:38, Max Zettlmeißl <max@zettlmeissl.de> wrote:
> There seems to be a problem with nested hash tables in the JSON
> library which I'm using.

This was exactly the problem. I fixed it now.
It's ridiculous that I began the program using the SourceHut GraphQL
API in November 2020 and thought that the variable support was broken
during all this time. All because the same format worked on GitHub.

Thanks for chiming in.

On Tue, 19 Oct 2021 at 22:31, Adnan Maolood <me@adnano.co> wrote:
> The following command works for me:
>
> curl \
>     -H Authorization:"Bearer $SRHT_TOKEN" \
>     -H Content-Type:application/json \
>     -d '{"query": "mutation ($name: String!) {\ncreateRepository(name: $name, visibility: PRIVATE, description: \"\") {\nname\nvisibility}\n}", "variables": {"name": "my-sourcehut-repository"}}' \
>     https://git.sr.ht/query

Thank you, this helped a lot. I thought I had already tried it with
Curl some months ago, but probably only tried debugging it with a http
library.
There seems to be a problem with nested hash tables in the JSON
library which I'm using.

On Tue, 19 Oct 2021 at 21:24, Joshua Mulliken <joshua@mulliken.net> wrote:
> We are missing a “,” here
>
> Hopefully that helps!

Sadly not, I just did not transcribe it properly from my client's output.
But thank you for trying.

I can't get GraphQL variables [2] to work properly with the Git API
and would appreciate some help.

For months I thought that this functionally was not added yet and
directly inserted the value into the query, but now is discovered and
example in the manual which uses variables [1], which implies that
GraphQL variables should be properly supported.

Currently the API returns the message "json body could not be decoded:
json: cannot unmarshal string into Go struct field RawParams.variables
of type map[string]interface {}" when trying to use variables as
specified at [1] or [2].
I tried to look up that format that "map[string]interface {}"
represents and the map I'm using should be correct.