Moderators should be able to just click a button next to each message, like when deleting messages.

Similar to what's described on https://www.reddit.com/r/JungleTV/comments/onnut1/crowd_funding/ minus some of the limits. Rate-limiting for enqueuing proposals coming from the same user can be implemented by increasing the down-payment with every successive simultaneous attempt, instead of hard-limiting to one proposal per user. In fact, it would be an interesting idea to make the down-payment amount increase with the number of active proposals, regardless of who made them - this means the number of active proposals can increase indefinitely, but at a cost to those wanting to increase it beyond reasonable points, much like what happens with the queue length factor in the main media queue.

Each active proposal gets a fixed payment address from the pool. Active proposals would need to be stored in the DB as to not lose track of their funds/state/address. The addresses would need to be taken from the pool again on start-up (this represents a change to how the address pool works, since right now it is kind of a "free list" that contains addresses that were once used and are free to use again. We'd need to introduce the concept of taking a specific address from the pool instead of just asking it for an arbitrary one.)

For reference in case the post is deleted:

We now have a proper database connection and "access framework" set up. Moderation decisions (users banned by who and when) can switch to using the database rather than a JSON file. With the right DB schema, we can also begin storing full ban/unban histories rather than past bans becoming almost untraceable when they're removed.

Allow moderators to pin chat messages and/or implement a different announcements system that can be seen even by users who don't use the chat.

As a viewer I would like to propose and vote on videos to be included in the auto-queued video list, which is played when there are no videos queued by viewers.
There could be rules for which kind of videos are eligible for proposing and voting on, e.g. must be banano-related, monkey-related, jungle-related or such.
Alternatively, a set list of e.g. 30 videos could be defined, viewers could vote once per day for one week, then the top 10 list would be used for the next week. The ideal numbers (e.g. 30/10) for that might be different.

Expand the list of good representatives and check that users have changed from the representative we gave them to another representative before finishing the verification process (any other representative, we don't to force them to switch to the one we suggest). Should go in hand with better explanations (#36) of what is happening on the 1st rep change and why the 2nd rep change is needed.

Show

• who has enqueued the most videos,-
• who has enqueued the longest video duration,
• who has spent the most Banano
• who has received the most Banano
• who has watched the most videos
• who has watched the longest

This depends on starting to collect per-user stats on a database. It is not expected that all metrics will be supported in the first version

Hovering over people's addresses in chat and queue could bring up an informational callout.

The callout could include:

• Complete banano address
• A QR code for the address (e.g. for easy tipping)
• The monKey in a larger size (remember to use the SVG version for this)
• (depending on how tricky the mouse/touch handling might be) explicit options to copy address and to reply to the hovered message

Once the system is sufficiently complete, this callout could also act as a kind of user profile preview, displaying some stats like the number of videos enqueued, chat messages sent, account age, etc.

Alternatively, instead of appearing on hover (might be tricky to manage on touchscreens), we could just increase the size of the "replying to message" component to include this info.

We have more and more informational pages (the main "what is this?" page, the guidelines, the FAQ, the leaderboards, and soon a couple more) which are not really discoverable. The top bar navigation, or the way the UI and website is organized as a whole, should somehow be changed to allow more direct access to these pages and to make them more discoverable.

We now have a proper database connection and "access framework" set up. Chat can begin to be persisted in a database rather than staying in-memory. There's a ChatStore interface that should make this easy enough.

This will also let us compute stats about the chat which could be intertesting for the leaderboards (#3).

For broadcasts, it can be tricky to see for how much longer they will play (one needs to subtract their duration from the time at which they began playing, and the UI doesn't show the latter).

It should be possible to obtain this information on the client alone, but it requires combining the media consumption checkpoints with the queue data. It might be easier to change the API so that this information (i.e. when the current entry started playing) is sent as part of the queue data.

Add bans that automatically expire after a moderator-set period. Bonus points if the moderation frontend offers options for preset periods (1 week, 2 weeks, etc.)

Right now user banning requires getting the super-admin to do it on the firewall - not ideal.

Create a page listing/promoting/identifying authorised third-party JungleTV merch sellers and other trusted/affiliated entities.

Blocked by #42

Finding a place for this in the UI might be a challenge (maybe in the future Skip tab?). We might need to implement a chat commands system, but for discoverability we then need to fit a list of commands somewhere near the message box.

The address verification process should make a better effort at explaining the process to change representatives.

Materials that can help:

We need documentation on how to run both backend and frontend locally, what are the requirements to do so, an example secrets-debug.json file, etc.

Ideally we should have instructions for frontend developers to be able to develop against the production backend so they don't have to install Golang and Postgres and etc. just to make frontend adjustments.

Example:

I am using Firefox on Android and the chat tab/window constantly pops up the keyboard... may be something to do with where JS is setting the focus?

As a viewer I want to see a list of all online viewers who are active, i.e. currently being rewarded, so that I can click their name to mention them in chat to get their attention.

As a user who spent more that a defined number of BAN to queue videos I want to be rewarded with emojis, so I can show off my contributions,

It is called "+ ENQUEUE VIDEO" on the button

Then, in the QUEUE it says "Requested by..."

Logically, the request is what is enqueued.

User Story:

As a user living in a given country and using a browser set to the appropriate locale, I want to see UI Text in my language and see time and number formats according to the locale.
AND
be able to override the above settings by choosing a locale from a dropdown menu or profile setting.

This can be achieved by

• querying and evaluating the browser locale
• switch language and number formats to browser locale specific formats.
  There are internationalization (i18n) and localization (i10n) methods/functionalities available in most browsers. At least in Chromium-based and Mozilla browsers.

Prerequisites:

• Identify and list UI text items to be translated
• Utilize POEditor as a tool to crowdsource translation (I have experience in this and translators for ca. 20 languages at hand)
• Implement language files (preferably .json format (supported by POEditor, other formats work as well).
• Implement query and evaluation of browser locale
• Implement switching to locale specific version

Recommended approach:

Define a Project (in github) to track activities and use issues as activities for the back log.
I am volunteering to

• Plan and facilitate the project,
• Create all issues to cover activities
• Set up and maintain project in POEditor
• Assign translators
• Collect translations
• Provide .json files to the main project.
• Follow up with user feedback regarding translations and take corrective action as needed.

What do you think?

• Highlight users who have recently enqueued a video in chat (say, in the last 4 hours). Maybe give additional flairs for the 2nd, 3rd, etc. video?
• Highlight the requester of the currently playing video in some other way.

Potential problem: performance issues checking this information as chat messages are sent. Moar caches?

The objective is to make the experience better for people with slower connections. At the start of each video or when the page is loaded, the player will still be loading itself or loading the initial video buffer, and with us forcing the video forward every 3 seconds, the player may get stuck in a loop where it never finishes downloading that initial buffer. Alternatively, we could try to see how much of the video is buffered and use that to make decisions, if the player API still lets us get that info (it used to, in the past; not sure about its current version).

This is strictly a frontend change, the backend should just continue sending media consumption checkpoints like normal - it's up to the client whether to obey them.

Chat seems to stop autoscrolling to the latest messages, mainly when the page is left in the background.

As a mod I want to have a one-click solution which will I instantly skip a bonbi-video, play a default "B-b-b-b-b-bonbibreaker!!" video (yet to be created), and add the skipped video to the blocked videos mentioned in #27 so that skeaked in bonbi-fart videos can be dealt with quickly.

As a jungleTV viewer i want to use Emojis in chat in order to express myself in a convenient way without having to copy/paste Emojis from somewhere else.

Recommended approach:
Implement an Emoji Chooser next to the chat input field, where I can choose Emojis from.

Add a Skip button that, when clicked by 10% of the active viewers, skips the current video. There's already similar functions in multiplayer games, like in Minecraft a certain percentage of users can sleep at night to make the game skip to the next morning. Presumably only bad (mmmkay) and/or offensive videos would end up being skipped.

Let moderators store notes and warnings for each user. Warnings could be like notes, except they trigger the sending of a public chat message informing the user they were warned. (Also consider giving moderators the option to send a similar message when banning users?)

Suggest making UI improvement so that when user selects Leaderboard, Rewards, About, etc., that the link opens in a new window versus navigating away from the stream. Or instead of new pages, make these items pop-over boxes (I don't actually like this idea, but is another possibility).

This is tricky because the gRPC handler which receives the chat messages doesn't have a way to get the spectator that corresponds to the sender. I suppose it could tell the rewards handler "hey, user with BAN address XYZ just sent a message so mark it as active" and the rewards handler goes through all spectators with that BAN address and marks them as active.

Moderators should be able to control a list of videos that should not be able to be enqueued.

Moderators should be able to use a button on the moderation queue to blacklist a video in addition to removing it.

Right now, the Chat component never removes any old chat messages, which means the number of DOM elements increases endlessly.

Right now, this requires recompiling and restarting the server.

Moderators should be able to adjust this multiplier.

The name JungleTV is already in use.
There is JungleTV. Video production company located in St. Lucie West.
https://www.jungletv.com/

My suggestion: JungleLive

Now that we've prepared the sidebar for an unlimited number of tabs*, also explore the possibility of letting moderators open the chat history for specific users in new sidebar tabs

*Might not actually be ready for dynamic tab creation/removal

Reward distribution is too slow with high user counts. It is not directly related to the time it takes to generate work for transactions, since even with a GPU (remotely connected) it can only send about 2 transactions per second.

The bottleneck is not very clear yet. It's possible that our node takes too long to accept the blocks, or maybe the roundtrips between application, work server and Banano node are taking too long.

Ideas:

• Move the Banano node closer to the application
• Move the application closer to the work generator/GPU
• Stop sending everything from the same account so sends can be parallelized
• Keep a balance for each user and pay out automatically only when they reach a certain threshold, and give them the option to withdraw manually at any time

Kalium probably supports some sort of protocol we can use to place a link on the payment page in order to simplify things for mobile users.

We now have a proper database connection and "access framework" set up. Queue persistence can switch to using the database rather than a JSON file.

Moderators should have the ability to mute users in chat.

Using Firefox on Android

The quick link from the enqueuing page sometimes fills in an incorrect amount for the payment... example: the base enqueue price could be 18.5 BAN and the link will pop up in Kalium with an amount of 38 BAN. This is with no special options selected such as queue jumping or skipping or unskippable.

Thanks for all you do!

We might need to keep two instances of the markdown-to-html thing around, one which does links and another which doesn't do links.

JungleTV could support other types of online media besides YouTube videos, as long as these can be legally embedded on 3rd party pages.

• YouTube streams (users would specify how long the stream should play for, and pay accordingly)
• Twitch streams (same thing)
• SoundCloud audio tracks (still subject to length limits like YouTube) - not sure if their player is controllable via API, but I think it at least used to be

Much of the system was originally modeled with this in mind, but some corners have been progressively cut in order to meet deadlines, so to speak. So some things are not as "generic" as they could be.