By dropping some of the less likely-to-be-used items.
---
 srht/flask.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/srht/flask.py b/srht/flask.py
index fee67de..e6c3a90 100644
--- a/srht/flask.py
+++ b/srht/flask.py
@@ -445,6 +445,7 @@ class SrhtFlask(Flask):
             else:
                 # Set user info cookie
                 user_info = g.current_user.to_dict(first_party=True)
+                user_info = {k:v for k,v in user_info.items() if k not in ['bio', 'location', 'url']}
[message trimmed]

NOTE: sending this a second time. My mail server failed to deliver the 
first on, because your MX record is not returned by 9.9.9.9. It _is_ 
being returned by 9.9.9.10, which I suppose means either Quad9 considers 
your domain malware, or your DNSSEC is not set up right. Just FYI :)


Hi,

On 9/17/23 00:52, Tom Tobin wrote:
> I just signed up today, and I'm consistently getting a 502 Bad Gateway error when attempting either of the following:
> 
> - Logging in via https://meta.sr.ht/login
> 
> - Updating my profile via https://meta.sr.ht/profile

Hi,

On 9/17/23 00:52, Tom Tobin wrote:
> I just signed up today, and I'm consistently getting a 502 Bad Gateway error when attempting either of the following:
> 
> - Logging in via https://meta.sr.ht/login
> 
> - Updating my profile via https://meta.sr.ht/profile
> 
> I'm attempting to log in from a new browser profile; I don't know if I'll lose access if I log out from my original profile.
> 
> For the profile update, it seems to actually succeed (as in, the profile text is saved) despite the error.
> 
> As per the instructions on the meta.sr.ht tracker, I'm posting here first.

Hi Vlad,

On 9/4/23 17:51, Vlad-Stefan Harbuz wrote:
> I think it's cool that you thought of documenting this! At the same
> time, I think a tutorial, while nice, is not the solution. I shouldn't
> have to read a tutorial to know how to use the website. The biggest
> problem with projects currently is that the UI is just very confusing.
> It's not at all clear what thing is part of which project, what kinds of
> things can be part of a project, and how to navigate between different
> things within a project.

I think we all agree that there is much to be improved in the UI. I 
think this will come once the dust has settled on the GraphQL 
federation. That said, even a good UI in my opinion does not obviate the

Hi Diederik,

thanks for the detailed feedback! I'll refrain from the quoting dance to 
keep this legible, but to sum it up:

Totally agree that I went a bit off the rails with regards to comparison 
with other forges. The folks who do come from GitHub/GitLab/whatever are 
a main target group, but basing this solely on comparison does indeed 
not make for a nice tutorial.

I'll restructure the document accordingly and also elaborate on the 
examples a bit, and it's proabably worth mentioning the "wizard" as well.

Cheers,

Signed-off-by: Conrad Hoffmann <ch@bitfehler.net>
---
 message/header.ha | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/message/header.ha b/message/header.ha
index 51d46a8..f3d7ff5 100644
--- a/message/header.ha
+++ b/message/header.ha
@@ -316,7 +316,7 @@ export fn read_header(
 	// TODO: leaks on error
 	let head = new_header();
 
-	match (bufio::scanbyte(&rd)?) {
[message trimmed]

On 9/4/23 17:40, Robin Jarry wrote:
> Gentle bump again. Could an admin have a look at the logs?

I did, but couldn't really find anything relevant. I suspect there might 
be a bug involved, either something systemic with webhooks, or some 
botched error handling that your specific webhook is hitting. I'll look 
into it, but it might take a moment.

Cheers,
Conrad

Thank you both for these great responses!

I had in the meantime gained at least some of the insight provided by 
removing the hash tables from the musl version and seeing its 
performance drop to the same level as the stdlib one. So I 100% agree 
that a lower-level issue is at play here. More inline.

On 9/3/23 06:18, Ember Sawady wrote:
> On Fri Sep 1, 2023 at 7:43 PM UTC, Bor Grošelj Simić wrote:
>>> This seems a bit surprising to me. The two-way algorithm is faster than
>>> the "brute force" method, but it already gets beaten significantly by
>>> just "inlining" the call to bytes::equal(). I also fail to explain to
>>> myself how the inlined version can be so much faster. The most likely
>>> explanation would of course be "function call overhead",

Hopefully addresses the common pitfall amongst new users that is the
creation of projects and their usage.

Signed-off-by: Conrad Hoffmann <ch@bitfehler.net>
---
Any feedback welcome, especially from new(-ish) users!

 tutorials/index.html             | 13 ++++++
 tutorials/organizing-projects.md | 69 ++++++++++++++++++++++++++++++++
 2 files changed, 82 insertions(+)
 create mode 100644 tutorials/organizing-projects.md

diff --git a/tutorials/index.html b/tutorials/index.html
index db7a5be..d130880 100644
[message trimmed]

The current suggestion has been removed from F-Droid. Suggest Aegis
instead, which Does The Job(TM), has some decent features, and seems
reasonable well-maintained.
---
It's pretty much the only TOTP app I've ever used, but if there are
valid reasons to not recommend it, please shout.

 metasrht/templates/totp-enable.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/metasrht/templates/totp-enable.html b/metasrht/templates/totp-enable.html
index d25ed26..11291e0 100644
--- a/metasrht/templates/totp-enable.html
+++ b/metasrht/templates/totp-enable.html
[message trimmed]