On 6/3/2021 8:39 AM, Ondřej Synáček wrote:
> I am not sure if the channel on Freenode is maintained "officially"
> from `aerc` contributor team but wanted to ask: Are there any plans
> to move to Libera or not?
> 

The official `#` channel was closed down and then seized by freenode 
staff and redirected to `##`. I don't see a aerc channel on libera, but 
the one on freenode definitely isn't official.

-gildarts

On 6/3/2021 3:26 AM, Simon Ser wrote:
> I'm still not a fan of shoe-honing the network name into the password
> field. Putting it in the username or nick is already a hack.
> 
> I'd rather see clients patched to support changing the username/nick.
> I don't think clients should update their settings (ie. their
> configured username or nick) when the server changes it.

Yeah, that is fair. I might keep tinkering on this to use on my local 
instance just for getting it working for now.

IRCCloud has relatively good reasons for not allowing changing username 
because of the abuse vector. There are already people who use them for 
abuse, but they are relatively easy to block because of the static ident

On 6/1/2021 3:53 PM, gildarts wrote:
> Prompted by conversation on IRC about enabling tools like IRCCloud
> to specify information inside of the password field, since they
> don't allow configuring the username field, etc.

Okay, ignore this patch. I need to send a v2 after I resolve some bugs.

-gildarts

Prompted by conversation on IRC about enabling tools like IRCCloud
to specify information inside of the password field, since they
don't allow configuring the username field, etc.

Doesn't prevent `:` user in passwords.

This is adding a fallback for authentication to allow providing
username, client, and network inside the password field.

It splits on `:`, but only if the password fails to be recognised
initially.
---
 downstream.go | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)
[message trimmed]

On 4/16/2021 11:07 AM, Страхиња Радић wrote:
> On 21/04/16 09:45, gildarts wrote:
>> How would that work?
> 
> 	This is all hypothetical, but still there is a potential. A big tech
> spying corporation could use any means it already uses to gather data about a
> user.  When a user accesses a server that is known to set the header telling
> "not to gather information" (IDK, maybe information obtained by something as
> simple as a crawler?), the user gets that habit associated with his/her 
"social
> profile" or however else one would call it. The corporation could then, 
for
> example, dedicate more resources/attention towards tracking the user, or use the
> information in whetever other way it sees fit. It is a bit of data about a user

On 4/16/2021 8:12 AM, Страхиња Радић wrote:
> 	Not at a per-user level. It could mark the server as potentially more
> interesting target for harvesting.
> 

How would that work?

If the server isn't even receiving any of this data, why would it be a 
target? DNT has obvious value tracking since so few people set it, but I 
really can't see how the **server** setting a header value is going to 
do anything other than preventing them from receiving data that they 
don't want.

-gildarts

On 2/11/2021 10:27 AM, Jean-Christophe Helary wrote:
> How can I remove the "~brandelune/applescript/" part ?

You can't unless you are running your own man.sr.ht instance. The main 
site wiki is a special case, any user wiki will be prefixed with your 
username and wiki name.

-gildarts

On 2/5/2021 2:20 PM, Mehdi Sadeghi wrote:
> Using Thunderbird I can sign and send emails (just tried). I have 
> different sub-keys for signing and encrypting. This email should arrive 
> signed too.
> 
> - Mehdi
> 

Yep it arrived signed. The question is if sr.ht can use the public key 
you uploaded to encrypt a message for you.

And you mention Thunderbird, did you create the key inside of 
Thunderbird? I have been unable to add any key created with Thunderbird 
to sr.ht after several rounds of trying.

In addition to what Drew said, I would double check that the key is 
setup for both signing and encrypting, as you can create keys for each.

-gildarts

On 1/20/2021 10:17 PM, Eli Schwartz wrote:
> I solved this problem by writing a simple wrapper around git which 
> prevents a lot of things from being checked out into ~/, including the 
> .git/ directory as I don't believe it's wise to make git commands fail 
> outside of a git repo by... acting on your dotfiles repo.

I've always just checked out my dotfiles repo to `~/.dotfiles` and 
symlinked the files into `~`. Is there a compelling reason to not go 
that route? I just seemed cleaner to me. Only difficulty is creating the 
symlinks, but you can script that or use other methods.

-gildarts