~maxz

Recent activity

Re: OAuth 2.0 for SourceHut services? 1 year, 4 months ago

From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss

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

Re: Is Sourcehut carbon-neutral? 1 year, 4 months ago

From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss

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

[PATCH] Correctly state the wrapping behaviour of Gmail. 2 years ago

From Max Zettlmeißl to ~sircmpwn/public-inbox

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]

Re: Problem using GraphQL variables 2 years ago

From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss

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.

Re: Problem using GraphQL variables 2 years ago

From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss

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.

Re: Problem using GraphQL variables 2 years ago

From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss

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.

Problem using GraphQL variables 2 years ago

From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss

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.