glimesh / glimesh.tv Goto Github PK

https://github.com/Glimesh/glimesh.tv/blob/master/config/dev.exs#L32

Currently, bans are stored globally on a temporary :ets table. We created a user_moderation_log channel, but I think we'll need something a bit faster for checking if a user is banned in a specific channel.

Not just moderation tools for channel mods but moderation tools for global mods. IE: A way for global mods/staff to shut a stream down and ban them from the platform. Various tools for staff to use to moderate channels themselves.

List of tools that would be needed:

• Temp ban streamer(when you view the stream page it returns a message stating they're currently banned)
• Perm ban streamers(Same as above but they'll only ever be unbanned manually)
• Stop stream(if someone hijacks someone else's stream, allowing staff to cut the stream off)
• Chat moderation tools(timeout, ban, slowmode, follower only mode, sub mode, etc.)

These tools would be placed behind a staff dashboard and I would recommend requiring something like Cloudflare Access(like a company VPN but not garbage) to be used to lock people out of the panel even if they somehow get the staff's login credentials.

Reported on Discord:

When you type too long of a message in someone's chat it doesn't show an error message it just doesn't send at all.
I press enter and nothing happens lmaoo

Should allow for Twitter as a social login that users can use to get started a bit quicker. This should also replace the current "type in your username" method.

Should include:

• Follows
• Chats
• Subscriptions

This is an early idea, but we could offer a login with Twitch button that allows users to automatically pull over any data we can get from them, and load it up into the users profile.

There's also a potential here of using this as a discovery feature, so you can immediately find your friends on Glimesh!

Users should be able to subscribe to the platform to help fund us directly, and get some neat perks.

This should also be inside the live view, so viewers get updates as it changes.

Fields:

• Title
• Description

when adding your social accounts it does not strip out the @ character at the beginning of the account name. it is quite common for users to refer to their twitter/instagram page(maybe others too) prefixed with an @ symbol. when the link is generated for the profile page it also includes the extra character

Basic categories:

• Games
• Art
• Music
• Tech
• IRL
• Teaching

This issue tracks implementing a load balancing solution for the Janus streaming back-end so that streams that are ingested can be replicated across several "edge" nodes that users will connect to via WebRTC for viewing.

Right now, we're using Google's CDN for serving fonts to our users. This also means we are sending them data about our traffic, usage and users.

I do not want to utilize Google as a CDN provider. So we need to self-host these fonts on our platform.

email addresses are validated only to contain an alphanumeric prefix, an @ symbol, and an alphanumeric suffix. cykotiq@localhost would be valid for example. At minimum it should check for a valid iana TLD (.com, .net, etc)

The complexity requirements for displayname/password/username are good candidates to be pulled out into a config file or constant somewhere. Might be outside the scope for this change though. We can open an issue on it if we think it's worth addressing later.

Originally posted by @haydenmc in #33 (comment)

Currently https://glimesh.tv/ClOnE1018/profile does not resolve my profile. We'll probably need to either slugify all usernames, or ensure where statement searches independent of the case.

We're getting a lot of people hit www. our domain, which causes Phoenix to freak out a bit.

app_1  | 21:50:50.251 [error] Could not check origin for Phoenix.Socket transport.
app_1  |
app_1  | Origin of the request: https://www.glimesh.tv
app_1  |
app_1  | This happens when you are attempting a socket connection to
app_1  | a different host than the one configured in your config/
app_1  | files. For example, in development the host is configured
app_1  | to "localhost" but you may be trying to access it from
app_1  | "127.0.0.1". To fix this issue, you may either:
app_1  |
app_1  |   1. update [url: [host: ...]] to your actual host in the
app_1  |      config file for your current environment (recommended)
app_1  |
app_1  |   2. pass the :check_origin option when configuring your
app_1  |      endpoint or when configuring the transport in your
app_1  |      UserSocket module, explicitly outlining which origins
app_1  |      are allowed:
app_1  |
app_1  |         check_origin: ["https://example.com",
app_1  |                        "//another.com:888", "//other.com"]
app_1  |
app_1  |

Seems like https://hexdocs.pm/plug_canonical_host/readme.html might fix it?

Currently it directs to YouTube instead of Discord.

Using a library like this should help make this super simple:

https://emoji-button.js.org/

We have moderators currently in the system, however we need a way to invite moderators and see their actions.

Currently, the use of a purchased CSS theme prevents us from open sourcing the entire repository. We should really spend some time redesigning the interface to by owned by Glimesh.

https://github.com/Glimesh/glimesh.tv/blob/master/config/config.exs#L21

We can also decide if the primary nav should be driven by this table, or hardcoded for performance.

without this a bot/botnet could register every username on twitch and make legit registrations very difficult.

Could send an email to all admins on launch? Review queue later?

Add reCaptcha(or equivalent) to the registration page to stop bots from registering a bunch of accounts.

I can be convinced this doesn't fit into Glimesh, but I want to blog about our recent streaming success & help drive traffic to the site.

These would be nice to have to keep code contributions consistent. I can handle drafting them up, but clone would have to ultimately be the one to implement the templates. CONTRIBUTING.md I can make a PR for.

We must support other languages! Part of the scope of this ticket is figuring out how custom languages work with Phoenix.

Allow users to pop-out chat into it's own responsive window.

I'm starting this issue to track and discuss the approach for the video streaming infrastructure behind Glimesh.

AKA, how do the bits get from the streamer's OBS instance to an ingest server to the viewer's browser?

Today, for demo streams, we are utilizing OvenMediaEngine's fantastic software, which allows for RTMP ingest, routing from origin server to various edge servers, and playback via WebRTC in the browser. The latency is impressive, but still a tad above 1 second. I suspect this is at least in part due to the RTMP protocol used to transmit from OBS to the OME Origin server. Unlike FTL, RTMP utilizes TCP transport, which introduces some additional latency in order to guarantee delivery of packets and packet ordering.

FTL utilized a UDP transport, which does not guarantee packet delivery or packet ordering, but operates at maximum speed. This is the transport utilized by most real-time applications (gaming, audio/video chat, etc.)

A quick test utilizing Janus WebRTC gateway with an RTP (UDP-based) ingest showed some very promising latency (disclaimers being that this is 1 viewer, no load balancing, Seattle<->SFO connection):

It may be possible to create a Janus plugin to accept FTL connections and use this to ingest streams on a UDP transport - effectively what Mixer was doing. This also means that the existing FTL output plugins on OBS would be supported, so streamers wouldn't need to use any additional software to enjoy low latency streaming on Glimesh. Currently investigating this option!

Users should be able to support their favorite streamers through a monthly subscription to their content.

OvenMediaEngine has been a great software that has successfully hosted numerous streams for Glimesh. However there are a couple of mis-fits of our product's requirements.

1. No authentication support
   There's preliminary support for signed keys, AirenSoft/OvenMediaEngine#68 but the implementation is not entirely clear yet.
2. No native load balancing between origins / clients
   Need some mechanism for load balancing clients geographically and based on load.

I'm proposing we create a middleware microservice to handle the authentication handshake based on the stream key, and locate the streamer geographically. The ideal state is then the microservice just proxies packets directly to OME.

I think right now if you have two streamers, their chat is pub-sub'd to both locations, and then if you refresh it goes away.

Will require having two separate docker-compose.yml files and (most likely) two separate Dockerfiles.

This issue tracks developing a Janus FTL plugin so we can ingest FTL streams via Janus.

You should be able to follow with your favorite content creators, and view a listing of which of them are live.