Explara integration

[kracekumar]

• This version doesn't take care of cancelling ticket since explara doesn't provide api for it.
• Email notification isn't sent to participation if transaction succeeded. Explara (cc avenue) sends email to buyer but HasGeek name isn't mentioned.

[jace]

Telegram has image and video sharing distinct from file sharing. Images and videos are always processed, but files are sent as originals. However, if the file contains an image, it is thumbnailed and displayed as an image.

[jace]

Multi-part images add an additional complication because they straddle the concepts of image, album and video.

• GIF images are an album (by spec) but rendered as a video (by practice)
• PDF files have multiple pages, with each having its own aspect ratio, effectively representing an ordered album of vector images
• Apple's live images are a video with a preferred still frame

If we spec image, album and video as distinct concepts, we'll have to force transform source files to fit one of these concepts.

The GIF format and Telegram's stickers add a new concept: an animation. Animations are treated as images that start animating when in focus (ie, visible in viewport and window has focus). They are distinct from videos, which cause the operating system's media controls to activate.

[jace]

libvips appears to be a suitable replacement for Pillow and ImageMagick as an image processor. There are Python bindings (pyvips), and performance benchmarks. https://github.com/libvips/libvips/wiki/Speed-and-memory-use

[jace]

Tentative database models:

1. File: Represents a raw uploaded file. This may or may not be processed immediately after upload (strip EXIF tags, minify SVG, etc), so it is stored with two content hashes: of the original file as uploaded, and of the current contents. The original hash is used for deduplication.

   File models are not linked to a user. Like with the EmailAddress model, they are platform data, and use foreign key ref-counting to track usage. Unused files should be deleted after a timeout period (say 24 hours). The File record may remain even when a file is removed, to track historical data (same as with EmailAddress).

2. Gallery: Like with Commentset, represents a universal mechanism to add media files anywhere they are needed. ~Galleries may be limited to a single or multiple files, specified as a flag.~

3. Media: Join model between Gallery and File. Represents a specific rendering of the file (usually a custom crop, for eg with avatars), and maintains an internal representation of pre-rendered thumbnails.

   Models that support media (Project, Proposal/Submission) should have a gallery_id fkey. Ownership flows from this parent model. Gallery, Media and File do not track direct owners, but do track actors, the users who uploaded or created them. Optionally, when only a single file is desired, models can link directly to the Media model. However, Media will then need a nullable gallery_id, which will then make it possible to have orphaned Media rows (as with orphaned Gallery and File rows), making refcounting all the more critical.

~Since the Gallery and Media models are always associated, it may be efficient to have them as a single model with an array structure (Postgres htree or jsonb). However, this may complicate the fkey refcounting File needs.~

[jace]

This spec is problematic:

Media: Represents a specific rendering of the file (usually a custom crop)

It requires a whole file to be uploaded (regardless of size) and a crop to be applied server-side. However, cropping can also happen client-side as modern JavaScript is sufficiently advanced, and removing unwanted content before receiving media is better for user privacy. By doing client side cropping, we also remove the need for a File model, as its primary purpose is deduplication.

In addition, we need at least three other models:

1. Thumbnail: A render of media, representing the file that will actually be served.

2. Spec: A specification for what media is required, applied during the upload instead of the render. Typically an aspect ratio and a max size.

3. Viewport: Rules for rendering the image, implemented on the client side via CSS. Typically used for circular avatars or rounded corners, where the browser applies the viewport. The viewport spec is required separately from CSS rules as viewports may be shown as an overlay during image upload.

[jace]

Optionally consider using NudeNet to classify images for moderators.