Skip to content

Add filehost #562

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add filehost #562

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 75 additions & 0 deletions extensions/filehost.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
---
title: The Filehost ISUPPORT token
layout: spec
work-in-progress: true
copyrights:
-
name: "Val Lorentz"
email: "progval+ircv3@progval.net"
period: "2022"
-
name: "Simon Ser"
period: "2024"
---

# filehost

This is a work-in-progress specification.

## Motivation

This specification offers a way for servers to advertise a hosting service for
users to upload files (such as text or images), so they can post them on IRC.

## Architecture

This specification introduces the `draft/FILEHOST` isupport token.

Its value MUST be a URI and SHOULD use the `https` scheme. Clients MUST ignore
tokens with an URI scheme they don't support. Clients MUST refuse to use
unencrypted URI transports (such as plain `http`) if the IRC connection is
encrypted (e.g. via TLS).

Servers MUST accept OPTIONS requests on the upload URI. Servers MAY return an
`Accept-Post` header field to indicate the MIME types they accept.

When clients wish to upload a file using the server's recommended service, they
can send a request to the upload URI. The request method MUST be POST. Clients
SHOULD authenticate their HTTP request with the same credentials used on the
IRC connection (e.g. HTTP Basic for SASL PLAIN, HTTP Bearer for SASL
Comment on lines +36 to +39
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spirit of my draft was that servers would embed credentials in the URL, to allow uploading to third-party services. With your design, third-party services get connection credentials that are valid for the IRCd in the most common SASL scheme (PLAIN).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. This is an intentional design decision. The filehost server can forward the request to another server if need be.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but it still knows the password

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand?

What I meant is that the filehost server can be hosted by the same folks as the IRC server, can check the credentials in the request, and can forward requests without IRC credentials to another server if need be.

Here's why I deviated from your proposal:

  1. Putting secrets in URLs is a bit scary. ISUPPORT is in general not security-sensitive.
  2. The upload service cannot be any random third-party: it needs to implement the spec's endpoints. In general, third-party upload services have a custom API.
  3. With your proposal, the external service still needs to be somehow tied to the IRC server to check the credentials embedded in the request URL. Credentials need to be per IRC connection. With signed tokens you hit issues regarding revocation etc.
  4. It resulted in a lot of additional complexity in my server implementation. On the other hand, proxying is very simple (and implemented in soju).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I meant is that the filehost server can be hosted by the same folks as the IRC server

My point was that it doesn't have to be.

The upload service cannot be any random third-party: it needs to implement the spec's endpoints.

There's no endpoint, it's just a URL that accepts generic HTTP POST

With your proposal, the external service still needs to be somehow tied to the IRC server to check the credentials embedded in the request URL.

My thinking was that the IRC server would create token on the external service, not the other way around.

Putting secrets in URLs is a bit scary. ISUPPORT is in general not security-sensitive.

It resulted in a lot of additional complexity in my server implementation. On the other hand, proxying is very simple (and implemented in soju).

Those however, are good points. I'm sold.

OAUTHBEARER). Clients SHOULD use the `Content-Type`, `Content-Disposition` and
`Content-Length` header fields to indicate the MIME type, name and size of the
file to be uploaded.

On success, servers MUST reply with a `201 Created` status code and with a
`Location` header field indicating the URI of the uploaded file. Servers MUST
support HEAD and GET requests on the uploaded file URI.

Clients SHOULD gracefully handle other common HTTP status codes that could
occur.

## Examples

Example isupport token:

:irc.example.org 005 seunghye draft/FILEHOST=https://irc.example.org/upload

Example OPTIONS response:

HTTP/1.1 204 No Content
Allow: OPTIONS, POST
Accept-Post: image/*, video/*

Example POST request:

POST /upload HTTP/1.1
Host: irc.example.org
Content-Type: image/jpeg
Content-Disposition: attachment; filename="picture.jpeg"
Content-Length: 4242
Authorization: Basic c2V1bmdoeWU6bm8=

Example POST response:

HTTP/1.1 201 Created
Location: /upload/hoh5eFThae4e.jpeg