On 2019-02-15  6:17 PM, Dave Cottlehuber wrote:
> I've seen mainly "Bearer" used rather than token:
> 
> Authorization: Bearer a4a62c31b19d45b6ba969b31f14b40ac
> 
> [1]: https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml
> [2]: https://tools.ietf.org/html/rfc6750

Meh, this is *really* inconsistently implemented throughout the web.
There's no broadly agreed upon standard.

> Can we please have signed HMAC headers for outbound webhooks? This
> prevents spoofing:
> 

I appreciate the enthusaism... but I don't really want to support these
extra layers of authentication between the services upstream. This isn't
how it's designed to work and I think patching it to behave like this
isn't the sort of thing a good downstream should be doing.

I use prometheus for monitoring, grafana for dashboards, and hopefully
soon I'll also use alert-manager for alarming. Crontabs email me when
they fail, and there's a little code in core.sr.ht which sends me an
email whenever an exception occurs.

Use HTTPs? This isn't a bug, we don't have your SSH keys on the build
boxes.

Hi folks! Thanks again for kicking the tires during the Sourcehut alpha.
I'm now working on Sourcehut (and other FOSS projects) full-time thanks
to your support. My productivity is already way up as a result. Also:
big thanks to everyone who came out to the sr.ht meetup at FOSDEM!

Another thousand user joined us this month, and we now number 7,598 in
total. Welcome, everyone!

	SCHEDULED OUTAGE ANNOUNCEMENT

First, head's up that on Monday I'm moving Sourcehut into a bigger rack
at the datacenter, to make room for several new servers. This will cause
intermittent outages throughout the day. If all goes according to plan,
these outages won't last longer than a 10-15 minutes each.

I don't really want to use these, to be honest. It seems like a new and
unproved idea, and I'm trying to be conservative with the API design.

On 2019-02-15  6:19 PM, Simon Ser wrote:
> git+https://…
> git+ssh://…

My bad, this is better.

I vote for this:

https+git://url...
https+hg://url...

Also, please default to git if unspecified.

On 2019-02-15  6:20 PM, Ivan Habunek wrote:
> You should document how you will be treating duplicate subscriptions,
> e.g. if a webhook URL is subscribed to the same event mutliple times.
> This can either be handled by refusing the double subscription, or by
> delivering once per subscription.

I like the idea of refusing the double subscription.

> You could simplify this enpoint by allowing only one event per POST
> request. It's easy to make one request per event and in that case you
> could make the endpoint idempotent.

Less fond of this.

Hi folks. What follows is a rough spec for how I want the APIs for
*.sr.ht to be designed. Seeking your feedback.

						 SourceHut API design proposal

The SourceHut API will be a simple REST-inspired API, over HTTPS. Both
requests and responses will be encoded in JSON. This is a pretty basic
application of REST, but bear with the explanation for those who don't
know.

# Authentication

Authentication is done with OAuth and is already documented here: