@nekename

Dockerfile written, github publish action written, backend container published 🎉

https://github.com/nekename/fossim-backend/pkgs/container/fossim-backend

edit: oh yeah also update checker in the app and anonymous statistics collection

it’s all finishing touches in the client now!

added support for minimising the app to the system tray when closed as well as a settings menu to control the behaviour

pretty much just need to add some networked services like an update checker and statistics collection, write a readme and faq, and add a docker build for the backend

alright, as hinted before, Fossim now sends system notifications! (and of course i made sure it doesn’t send notifs when the channel is focussed and you’re actively chatting)

(weird icon and name will be fixed when the app is properly installed (i hope))

comments referencing github items are now real links to make coordinating PRs and issues way easier (as well as linking to other discussions, although they don’t open in fossim)

I also added a notif level setting which will be useful now as I’m about to implement system notifications, and you might not want a system notification for every thread in every community

this is amidst some other UI/UX improvements like better error messages, automatic reconnection etc

with all the architectural stuff done, I’m working on all the cosmetic finishing touches

community list now also shows the total unread notifs of all the community’s channels

community config allows specifying name, icon and banner so that you can customise your community

I even added a button to sponsor the community’s owner if the repository has funding links attached!

so, I’m back a little while later, and the app now shows unread message counters, not only incrementing while the app is open but also synchronising with the backend so that you can see how many messages have come in even when the app was closed.

this required me to set up a database in the backend for tracking sequential message counters for each channel that the client can then subtract from its own records, I learnt some database stuff and also some stuff about making bulk HTTP requests, since I didn’t want to make a request per channel

alright, here we go!

it was a lot of work (nearly 4h as you can see), but the Fossim client can now receive and handle every type of live update that the backend can receive from the GitHub webhook.

this means that when others send, edit or delete messages, or a new channel or thread is created or an existing one edited, deleted, locked or unlocked, the client receives the update in real time.

now it feels more like an instant messenger :)

what’s left: showing notifications for unread messages, including finding some way to remember last read message and fetch how many new messages once the client restarts

worked my way through GitHub docs and figured out how to implement a webhook delivery handler, including verifying the secret, then implemented connecting to websocket channels for each community which get forwarded all the relevant webhook messages

all that’ll be left now is to incorporate these updates into the frontend which shouldn’t be too hard

I added replying to messages that don’t already have a reply thread last night and I’ve just added reacting and unreacting, which completes all the basic message functions 🎉

you can now edit messages
basically i’m speedrunning all the basic actions so that i can work on notifications which will be a huge task

you can now delete comments and replies, including proper handling of GitHub’s very weird logic flow for deleting comments that have replies - they get replaced with ghost comments until all of their replies are deleted - just an empty body without so much as an explanation
(two windows here to demonstrate the modal and also the fact that the button appears on comment hover)

wow! you can now send messages from a delightfully previewable text box

in other news, I improved the experience switching between communities, added highlighting for the active channel, fixed a performance problem and fixed a hang when loading an empty channel

you can now view full reply threads to every top-level message, including pagination (it loads 100 messages at a time)

code block highlighting, bug fix

5 hours later, and basically all of the requirements of the main-continuity message view have been implemented, including images, lists, links, alerts, reactions and placeholder buttons for opening reply threads!

it even automatically loads more messages as you scroll upwards, but i dont have any long enough channels to demonstrate that (loads 100 messages at a time since that costs the minimum per request in terms of github rate limits)

all that’s left now is taking actions (sending messages, reacting etc), and then getting realtime notifications from the backend

I’m having so much fun :)
I’ve implemented the entire channel and thread list complete with thread pagination, dynamic icons based on locked/answered/answerable status, and a button to leave the community
I also implemented a really satisfying shift, blur and shadow effect when switching between communities
(edit: the issue in the video where the ‘select a community to start collaborating’ message wasn’t shown after leaving the community got fixed immediately after recording)

I learnt GraphQL and made my peace with it, then implemented listing channels and threads!

why is there no REST API for Discussions 😭
I’m going to have to learn GraphQL

auto-expanding sidebar drawer for communities you’re in, including a button and popup flow for joining new communities :)
caching from previous step was useful here
next step is listing channels and threads

1. added double-click to copy and added a loading ring animation to the device flow auth view
2. added a note to the host confirmation view saying that the app only has limited access to act on your behalf and that in the local app, the access token never needs to be sent to the server
3. cleaned up the database schema and implemented persisting added communities and obtained access tokens
4. implemented caching host and client ID requests since those will be frequent in upcoming stuff