20250326 Weekly Development Meeting

[josecelano]

• Time: 9:30 in Canary Islands (WET (UTC+0)).
• Time: 10:30 in Vaduz (CET (UTC+1)).

Location:

https://meeting.blockfinance-eco.li/nautiluscyberneeringweeklydevmeeting

Expected duration: 2 to 4 hours with breaks

Communicated attendants:

• Cameron Garnham (@da2ce7) - x
• Jose Celano (@josecelano) - x
• Constantin Bosse (@cgbosse) - x
• Mario Melchor (@mario-nt) - x
• Graeme Byrne (@grmbyrn) - x

---

Agenda:

1. Everyone will take their turn and:

• Go over his notes added as comments for the meeting which will have been added in advance to give an update of all the work done during the previous week indicating.
  • The issues worked on
  • The progress made on them
  • Other things done
• Inform of any faced challenges and request help if necessary to work on specific issues.
• Highlight the encountered difficulties, especially if there is a risk of them causing delays or affecting end product's quality.
• Communicate what will be the next week's tasks.
• List any new topics for further discussion in an additional Technical meeting that he noted for future discussion in comments to this discussion either before the meeting or after his turn so that they get considered.

During the meeting every team member will take their turns and follow this sequence.
The topics for further discussion will be noted in advance by each the team member and to the meetings agenda.

2. At the end of the meeting if there any new technical topics to be discussed further it will be decided to
   set another meeting date for the discussion of these or to hold the meeting hereafter.

Also the persons to be part of the meeting will be decided on so that the others will be free to continue their own work.

[josecelano]

Nautilus Website

PR reviews:

• Add ToggleTheme for dark/light mode nautilus-website#28
• Add Nautilus blog posts in SvelteKit nautilus-website#31

Torrust Website

PR reviews:

• Refactor blog section to use SvelteKit instead of Markdown torrust/torrust-website#146
• Fix brand colors torrust/torrust-website#147

Torrust Tracker

New issues:

• Include public service URL in configuration torrust/torrust-tracker#1417

Follow up discussions:

• Alternatives to the Tracker REST API torrust/torrust-tracker#1307 (comment)
• Peer and torrent specific statistics torrust/torrust-tracker#139 (reply in thread)

PR reviews:

• health_check: service type torrust/torrust-tracker#1413

PRs:

• Update dependencies torrust/torrust-tracker#1408 (update dependencies)

Issues:

My main focus this week has been the issue to collect segregated metrics.

• Overhaul stats torrust/torrust-tracker#1327
  • Overhaul stats: Segregated metrics for each tracker running on a different socket address torrust/torrust-tracker#1263
    • Overhaul stats: add a configuration option to enable/disable stats per server torrust/torrust-tracker#1401
    • Overhaul stats: start collecting stats per server instance (per socket) torrust/torrust-tracker#1403
      • There is a discarded PR (option 1)
    • Overhaul stats: add E2E tests for the global metrics torrust/torrust-tracker#1407
    • Overhaul stats: start collecting stats per server instance (per socket) torrust/torrust-tracker#1403
      • There is a draft PR with a Proof of Concept (option 2).
• Include service type in health check enpoint torrust/torrust-tracker#1409
• Make server listen URL available where server socket address is also available torrust/torrust-tracker#1415 (WIP)

My initial plan was to use separated services (in the AppContainer) per instance (option 1). There is a PR that I have discarded. I decided to use a singleton stats repository that stores the segregated metrics. The reasons are:

1. I don't want to introduce services per instance.

• It adds a lot of complexity.
• We don't have data to assume it would be better in performance.

2. I came up with a different way to store and expose metrics more aligned with the Prometheus format.

• This way should be easily extendable.
• One metric, multiple labels (option 2).

3. We have to collect again all the segregated the metrics from the instances to expose them via the API.
4. I don't think users are going to have a lot of services. I guess the most common scneario is one server per type (one HTTP tracker, one UDP tracker). Even is they have multiple I won't be hundreds of them.

To implement the solution in option 1, I had to refactor containers:

• Refactor: AppContainer to initialize all services in the setup phase torrust/torrust-tracker#1411
• Refactor containers torrust/torrust-tracker#1406 (refactor containers)

In the end, I'm not using one service per instance but the containers refactor is still valuable. It was a TODO commented on the code. The change will make it easier to change things related to containers in the future.

Note: Total time spent on Torrust ~31h.

[grmbyrn]

Torrust Website

Issues worked on:

• Convert Markdown-Based Blog to Full SvelteKit Implementation torrust/torrust-website#141
• Fix brand colors torrust/torrust-website#144 - Provided colours in PDF were visually different from design. Replaced the wrong hex colour from the PDF with the correct ones
• Alternative to the grey horizontal scroll bar in the key features torrust/torrust-website#145 - Discussed with Jose how to style the sliders on torrent-index and torrent-tracker pages

PRs

• Refactor blog section to use SvelteKit instead of Markdown torrust/torrust-website#146 - Converted all blog posts in Torrust website from using Markdown to use only SvelteKit
• Fix brand colors torrust/torrust-website#147

Closed issues

• Convert Markdown-Based Blog to Full SvelteKit Implementation torrust/torrust-website#141

Nautilus Website

Issues worked on:

• Migrate Blog Posts from Existing Nautilus Blog to SvelteKit Website nautilus-website#29 - Took all the contents of blog posts from https://nautilus-cyberneering.de/ and converted to appropriate HTML tags. Implemented tags and contributors routes. Stored images for each blog post in appropriate folder for image
  which changes colour scheme depending on whether the user has chosen dark or light mode.
• Set body max width nautilus-website#25 - Adjusted max-width on each page so that the content doesn't stretch too far across page but also maintains a good width and display on smaller screens

PRs

• Add Nautilus blog posts in SvelteKit nautilus-website#31
• Add ToggleTheme for dark/light mode nautilus-website#28 - Implemented CSS variables in SCSS global file

Opened issues

• Add search bar to blog page nautilus-website#32 - Add a search bar so that users can filter blog posts using a search term

Closed issues

• Finish contact page nautilus-website#26
• Fix link to projects page in homepage nautilus-website#27
• Dark mode toggle nautilus-website#14

[mario-nt]

Index (Time Spent 14hrs)

• New API endpoint to reset user's passwords torrust/torrust-index#802
  • Worked on:
    • Handler logic for the new users password reset API endpoint (WIP)
    • Service logic for the new users password reset API endpoint (WIP)
    • DB logic for the new users password reset API endpoint (WIP)

GUI (Time Spent 11hrs)

• Admins should be able to reset user's passwords torrust/torrust-index-gui#660
  • Worked on:
    • Forgot password link
    • Reset password page (WIP)
    • Send password reset component (WIP)

Closed issues

• Adding filtering and sorting options to listing user profiles endpoint torrust/torrust-index#801
• Clippy errors when running CI torrust/torrust-index#807
• Adding filtering and sorting options to listing user profiles endpoint torrust/torrust-index-api-lib#53
• Research on how to allow users/admin to reset passwords torrust/torrust-index-gui#706

Training (Time Spent 1h)

• https://vuejs.org/guide/
• https://vuejs.org/tutorial/#step-1

Next

• Finish GUI/Index reset password funcitonality
• Continue Vue basics training
• AI prompting tips
• Close open issues