~sircmpwn

Philadelphia, PA

https://drewdevault.com

I write code.

~sircmpwn/sr.ht-dev

Last active 2 hours ago

~sircmpwn/public-inbox

Last active 4 hours ago

~sircmpwn/sr.ht-discuss

Last active 4 hours ago

~sircmpwn/sr.ht-announce

Last active 8 hours ago

~sircmpwn/sr.ht-admins

Last active a month ago

~sircmpwn/wlroots-announce

Last active 7 months ago

Recent activity

Re: SourceHut API design proposal 3 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-dev

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:
> 

Re: Interaction between meta and services using OAuth 3 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-dev

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.

Re: sr.ht monitoring 4 hours ago

From Drew DeVault to ~sircmpwn/public-inbox

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.

Re: Cannot clone over ssh on builds.sr.ht 4 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-discuss

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

What's cooking on Sourcehut? February 2019 8 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-announce

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.

Re: SourceHut API design proposal 9 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-dev

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.

Re: Build manifests' sources 10 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-dev

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

My bad, this is better.

Re: Build manifests' sources 11 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-dev

I vote for this:

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

Also, please default to git if unspecified.

Re: SourceHut API design proposal 11 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-dev

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.

SourceHut API design proposal 13 hours ago

From Drew DeVault to ~sircmpwn/sr.ht-dev

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: