On 21/08/17 03:03, Drew DeVault wrote:
> Okay, this seems reasonable for us to support.

Hopefully, this will only extend, instead of replacing, the current behavior of
having license in the file LICENSE in the root of the repository?

On 21/08/14 08:10, Drew DeVault wrote:
> No, Markdown is the only supported format.

Plain text is as well. I'm using it for most of my repositories.

On 21/05/25 07:58, Armaan Bhojwani wrote:
> > This is a matter of privacy.
> 
> I simply don't see how a number of people subscribed is a privacy
> issue. A simple, entirely anonymous integer accessible only by
> list admins tells much less information than say server access logs that
> Sourcehut keeps.

Making and maintaining programs should ideally only be motivated by the
enthusiasm of the programmers, not social engineering and (Google) analytics. By
now everyone should recognize those two are harmful and should become a thing of
the past.

On 21/04/16 01:19, gildarts wrote:
> I'm open to the possibility I'm wrong on this, but I'm going to need you to
> describe a real mechanism for this to happen and matter for me to change my
> mind.

	If you ask about the possible scenario (which you already kind of
acknowledged by "may potentially work at least for a while") how this can be
detrimental, opting out of collecting "interest cohorts" would definitely prompt
Google that the server is openly opposing their "feature". How Google would
react would then entirely depend on them. If they wanted to retaliate, they
could for example lower the server's ranking in Google search to oblivion, or
they could make it so the server is treated as "malicious". I'm not them, so
IDK.

On 21/04/16 03:14, Tanguy Fardet wrote:
> But wouldn't that be against the legal value of the opt-out and 
> therefore usable against said company (making it useful)?

	There's a difference between easily machine-identifiable "value" and
actual human-readable "legal value" (in the form of terms of use or such).

>  From my point of view it:
> a) sends a message
> b) may potentially work at least for a while
> c) can be used as leverage in case of later abuse
> 
> Whereas not doing it has no positive outcome that I can see.

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
accessing such servers. The corporation could then - again: for example - track
frequency of visits, referrers, or use that information in ad targeting, etc
etc.

On 21/04/16 11:30, tom wrote:
> I may be a bit dense, but how is a http-server-side setting additional
> personal data?

	Not at a per-user level. It could mark the server as potentially more
interesting target for harvesting.

On 21/04/16 05:50, huyngo@disroot.org wrote:
> Google has launched trials of FLoC and that raises some privacy concerns.
> Fortunately, there is a way to [opt out][1] of this as someone who hosts websites: setting a HTTP Header
> 
> ```
> Permissions-Policy: interest-cohort=()
> ```
> 
> I hope sourcehut would advocate privacy by standing against this.

	This is similar to DNT[1] in expecting naive faith that it would be
actually used to not track users and not to additionally (along with tracking)
mark them as having something to hide, or at least openly mark them as opposing
tracking, which is just additional personal data.

On 21/03/31 11:53, Scott Colby wrote:
> Hello,
> 
> Just a few minutes ago, I pushed several commits to ~scolby33/scolbyblog,
> and I expected the build defined by the .build.yml there to trigger,
> as it has in the past. I first noticed that no link to the build
> was returned on my terminal by the server in response to the push;
> checking https://builds.sr.ht/~scolby33/scolbyblog/commits/.build.yml
> shows that indeed no build was triggered. I tried manually submitting
> the .build.yml's contents, and this worked:
> https://builds.sr.ht/~scolby33/job/474557.
> 
> Was there a momentary hiccup in the connection between git.sr.ht
> and builds.sr.ht, or have I done something wrong with my repo?

On 21/03/29 07:46, Drew DeVault wrote:
> Sometimes builds are not submitted due to transitive issues. Just try
> copying and pasting your build manifest into builds.sr.ht/submit. Using
> the "resubmit build" button will resubmit that *specific* build,
>less including the git tree which was checked out.

	Thanks, submitting over the web worked! :)