starred/godoxy-yusing
1
0
Fork 0
mirror of https://github.com/yusing/godoxy.git synced 2026-01-11 14:20:32 +01:00
Code Issues 18 Packages Projects Releases 10 Wiki Activity

Predefined categories #87

New Issue
Open
opened 2025-12-29 14:24:33 +01:00 by adam · 6 comments
adam commented 2025-12-29 14:24:33 +01:00
Owner
Copy Link

Originally created by @dacagi on GitHub (Jun 10, 2025).

Foreword

I only recently discovered this project and I've been implementing it side by side with my existing SWAG setup for a reverse proxy. I really like that this is simple enough for most people but also combines many features that would otherwise mean having separate services like Uptime-Kuma and Beszel for service and host monitoring respectively. I specially love its autodiscovery feature via providers, that's the most useful thing ever. In summary, congrats for such an awesome project, I'm super hyped and keep a close eye on it.

Question

That being said, my question/proposal was in relation to the predefined categories. I was looking to update the existing list with some more apps that I use and post a PR, and while I was doing that I noticed that I got some categories on my dashboard that I don't see mentioned in the categories.go file.

For example I got SearxNG categorized as Search, correctly, but I don't see the app or the category listed in the file. Also, Jellyfin appears to be under Media, but I got it listed in a new category Streaming. Similarly I got other services like Vaultwarden, Nextcloud, and even Filestash categorized but they don't appear at all in the file.

So my first question is, is there any other file I should be looking for which defines the categories used on the homepage? Where did these unknown categories come from?

Proposal

Second question, possibly maybe a feature too, what are your future plans around this? I would be willing to create a much bigger list of supported predefined services if you'd like me to. But then I thought about the difficulties around maintaining it up to date whenever new services come and go.

So I remembered as an example the well known and curated awesome-selfhosted list of apps, which kind of already does the same job. I was investigating the possibility of querying its dataset on awesome-selfhosted-data to externalize the issue. It provides not only service and category (tags) but also many other interesting details we could make good use of in the homepage dashboard.

I was wondering what your thoughts about these topics were, before I proceed further with either the PR to update the existing predefined list or a deeper investigation on the possibility to integrate an external tool to achieve similar results.

Originally created by @dacagi on GitHub (Jun 10, 2025). ### Foreword I only recently discovered this project and I've been implementing it side by side with my existing SWAG setup for a reverse proxy. I really like that this is simple enough for most people but also combines many features that would otherwise mean having separate services like Uptime-Kuma and Beszel for service and host monitoring respectively. I specially love its autodiscovery feature via providers, that's the most useful thing ever. In summary, congrats for such an awesome project, I'm super hyped and keep a close eye on it. ### Question That being said, my question/proposal was in relation to the predefined categories. I was looking to update the existing list with some more apps that I use and post a PR, and while I was doing that I noticed that I got some categories on my dashboard that I don't see mentioned in the [categories.go](https://github.com/yusing/godoxy/blob/main/internal/homepage/categories.go) file. For example I got SearxNG categorized as Search, correctly, but I don't see the app or the category listed in the file. Also, Jellyfin appears to be under Media, but I got it listed in a new category Streaming. Similarly I got other services like Vaultwarden, Nextcloud, and even Filestash categorized but they don't appear at all in the file. So my first question is, is there any other file I should be looking for which defines the categories used on the homepage? Where did these unknown categories come from? ### Proposal Second question, possibly maybe a feature too, what are your future plans around this? I would be willing to create a much bigger list of supported predefined services if you'd like me to. But then I thought about the difficulties around maintaining it up to date whenever new services come and go. So I remembered as an example the well known and curated awesome-selfhosted list of apps, which kind of already does the same job. I was investigating the possibility of querying its dataset on [awesome-selfhosted-data](https://github.com/awesome-selfhosted/awesome-selfhosted-data) to externalize the issue. It provides not only service and category (tags) but also many other interesting details we could make good use of in the homepage dashboard. I was wondering what your thoughts about these topics were, before I proceed further with either the PR to update the existing predefined list or a deeper investigation on the possibility to integrate an external tool to achieve similar results.
adam commented 2025-12-29 14:24:34 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Jun 10, 2025):

Hi, first of all, thanks for loving the project and willing to contribute.

Seems like I forgot to mention this on the wiki, those categories are from selfh.st's icons.json: https://cdn.selfh.st/directory/icons.json. I think it should be enough and we could remove the categories.go.

Thanks for the dataset, will consider using this as a fallback when categories not found from selfh.st's list. If you're interested to implement this, please have a look at internal/homepage/list_icons.go.

@yusing commented on GitHub (Jun 10, 2025): Hi, first of all, thanks for loving the project and willing to contribute. Seems like I forgot to mention this on the wiki, those categories are from selfh.st's icons.json: https://cdn.selfh.st/directory/icons.json. I think it should be enough and we could remove the `categories.go`. Thanks for the dataset, will consider using this as a fallback when categories not found from selfh.st's list. If you're interested to implement this, please have a look at `internal/homepage/list_icons.go`.
adam commented 2025-12-29 14:24:34 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Jun 10, 2025):

I see some interesting info there, I could add some of these to the homepage as well:

name: Accent
website_url: https://www.accent.reviews/ # this should be useful
description: Developer-oriented translation tool.
licenses:
  - BSD-3-Clause
platforms:
  - Elixir
  - Docker
tags:
  - Software Development - Localization
source_code_url: https://github.com/mirego/accent # also this
stargazers_count: 1401
updated_at: '2025-06-02' # also this
archived: false
@yusing commented on GitHub (Jun 10, 2025): I see some interesting info there, I could add some of these to the homepage as well: ```yaml name: Accent website_url: https://www.accent.reviews/ # this should be useful description: Developer-oriented translation tool. licenses: - BSD-3-Clause platforms: - Elixir - Docker tags: - Software Development - Localization source_code_url: https://github.com/mirego/accent # also this stargazers_count: 1401 updated_at: '2025-06-02' # also this archived: false ```
adam commented 2025-12-29 14:24:35 +01:00
Author
Owner
Copy Link

@dacagi commented on GitHub (Jun 11, 2025):

My bad, guess I didn't even consider where you'd be getting the icons from, that makes sense now.

I'm not versed in Go programming so I may not be the best candidate for such a big refactor. From why I seem to understand, you're getting most data from selfh.st including category from tags, then completing missing icons from walkxcode right?

homarr-labs/dashboard-icons aka walkxcode has categories and aliases, but I've found too many services without them. So it makes sense you only consider this source as backup icons. It currently has 1967 icons, the biggest dataset of following comparison.

{
  "base": "svg",
  "aliases": [
    "paywall-remover",
    "article-unblocker"
  ],
  "categories": [
    "Web-Browsers"
  ],
  "update": {
    "timestamp": "2024-10-13T18:25:47Z",
    "author": {
      "id": 46011270,
      "name": "mcmikemn"
    }
  }
}

selfh.st/icons has categories and tags (on their CDN version only), but most categories are simply "Self-Hosted" or "Other" and only 381 items have tags that we can read from. It currently has 1773 icons.

{
    "Name": "Bitwarden",
    "Reference": "bitwarden",
    "SVG": "Yes",
    "PNG": "Yes",
    "WebP": "Yes",
    "Light": "Yes",
    "Dark": "Yes",
    "Category": "Self-Hosted",
    "Tags": "Passwords",
    "CreatedAt": "2024-08-20 09:06:30+00:00"
},

But I also saw the selfh.st/apps repo which could be an interesting solution too. It has far more data points than the icons repo (including tags), but on the other hand it has fewer services, only 997.

{
    "Id": 308,
    "Project": "n8n",
    "Reference": "n8n",
    "Sponsor": null,
    "Sponsor URL": null,
    "Website": "https://n8n.io",
    "Repository Link": "https://github.com/n8n-io/n8n",
    "Description": "Extendable workflow automation tool to easily automate tasks",
    "License": "Custom",
    "Language": "TypeScript",
    "Icon Source": "Icons",
    "Icon Override": null,
    "Icon Modifier": null,
    "selfh.st/icons": null,
    "Source": "GitHub",
    "Stars": 106024.0,
    "Stars (Display)": "106k",
    "Latest Commit": "2025-06-10",
    "Latest Commit Color": "Green",
    "Tags": "Workflow Automation",
    "Dynamic Filter": "IFTTT,Zapier",
    "Age": 2181,
    "CreatedAt": "2024-09-12 13:19:42+00:00"
},

Lastly, there's awesome-selfhosted-data with I believe 1266 services. It does not have icons, and most if not all of the data is already present in selfh.st/apps.

name: AdGuard Home
website_url: https://adguard.com/en/adguard-home/overview.html
description: User-friendly ads & trackers blocking DNS server.
licenses:
  - GPL-3.0
platforms:
  - Docker
tags:
  - DNS
source_code_url: https://github.com/AdguardTeam/AdGuardHome
stargazers_count: 28709
updated_at: '2025-06-10'
archived: false

All of this to say that maybe my awesome-selfhosted-data proposal wasn't as good as I initially thought.

You've already coded ability to parse json from selfh.st/icons. It would probably be far easier to adapt and extract from selfh.st/apps too, if we want to extract project details like github repo and last commit date.

The apps repo is not included in the same CDN as the icons, but I've seen the site fetches from selfhst.github.io. Hopefully this is a feasible solution without getting into Github rate limits since you use an internal cache for the icons anyway.

@dacagi commented on GitHub (Jun 11, 2025): My bad, guess I didn't even consider where you'd be getting the icons from, that makes sense now. I'm not versed in Go programming so I may not be the best candidate for such a big refactor. From why I seem to understand, you're getting most data from selfh.st including category from tags, then completing missing icons from walkxcode right? [homarr-labs/dashboard-icons](https://github.com/homarr-labs/dashboard-icons/tree/main/meta) aka walkxcode has categories and aliases, but I've found too many services without them. So it makes sense you only **consider this source as backup** icons. It currently has 1967 icons, the biggest dataset of following comparison. ```json { "base": "svg", "aliases": [ "paywall-remover", "article-unblocker" ], "categories": [ "Web-Browsers" ], "update": { "timestamp": "2024-10-13T18:25:47Z", "author": { "id": 46011270, "name": "mcmikemn" } } } ``` [selfh.st/icons](https://github.com/selfhst/icons) has categories and tags (on their [CDN](https://cdn.selfh.st/directory/icons.json) version only), but most categories are simply "Self-Hosted" or "Other" and **only 381 items have tags** that we can read from. It currently has 1773 icons. ```json { "Name": "Bitwarden", "Reference": "bitwarden", "SVG": "Yes", "PNG": "Yes", "WebP": "Yes", "Light": "Yes", "Dark": "Yes", "Category": "Self-Hosted", "Tags": "Passwords", "CreatedAt": "2024-08-20 09:06:30+00:00" }, ``` But I also saw the [selfh.st/apps](https://github.com/selfhst/apps) repo which could be an interesting solution too. It has far more [data points](https://github.com/selfhst/apps/blob/main/data/software.json) than the icons repo (including tags), but on the other hand it has fewer services, only 997. ```json { "Id": 308, "Project": "n8n", "Reference": "n8n", "Sponsor": null, "Sponsor URL": null, "Website": "https://n8n.io", "Repository Link": "https://github.com/n8n-io/n8n", "Description": "Extendable workflow automation tool to easily automate tasks", "License": "Custom", "Language": "TypeScript", "Icon Source": "Icons", "Icon Override": null, "Icon Modifier": null, "selfh.st/icons": null, "Source": "GitHub", "Stars": 106024.0, "Stars (Display)": "106k", "Latest Commit": "2025-06-10", "Latest Commit Color": "Green", "Tags": "Workflow Automation", "Dynamic Filter": "IFTTT,Zapier", "Age": 2181, "CreatedAt": "2024-09-12 13:19:42+00:00" }, ``` Lastly, there's [awesome-selfhosted-data](https://github.com/awesome-selfhosted/awesome-selfhosted-data) with I believe 1266 services. It **does not have icons**, and most if not all of the data is already present in selfh.st/apps. ```yaml name: AdGuard Home website_url: https://adguard.com/en/adguard-home/overview.html description: User-friendly ads & trackers blocking DNS server. licenses: - GPL-3.0 platforms: - Docker tags: - DNS source_code_url: https://github.com/AdguardTeam/AdGuardHome stargazers_count: 28709 updated_at: '2025-06-10' archived: false ``` All of this to say that maybe my awesome-selfhosted-data proposal wasn't as good as I initially thought. You've already coded ability to parse json from selfh.st/icons. It would probably be far **easier to adapt and extract from selfh.st/apps** too, if we want to extract project details like github repo and last commit date. The apps repo is not included in the same CDN as the icons, but I've seen the site fetches from [selfhst.github.io](https://selfhst.github.io/apps/data/software.json). Hopefully this is a feasible solution without getting into Github rate limits since you use an internal cache for the icons anyway.
adam commented 2025-12-29 14:24:36 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Jun 12, 2025):

Thanks for the info. Will have s look later

@yusing commented on GitHub (Jun 12, 2025): Thanks for the info. Will have s look later
adam commented 2025-12-29 14:24:37 +01:00
Author
Owner
Copy Link

@dacagi commented on GitHub (Jun 12, 2025):

As already mentioned I'm not well versed in Go, but since we now have AI to help us, I decided to try and see what I could achieve today.

I won't open a PR unless you tell me to do so, I have limited trust in AI agents. Since it was me who proposed the changes I wanted to help as much as possible.

Please review my feat/app-metadata branch and let me know if this is even helpful. Do not hesitate to discard if useless.

App Metadata Integration Summary

Implemented a new metadata system that provides rich application information while maintaining backward compatibility with the existing icon system. The implementation tries to follow a clean separation of concerns and allows for gradual adoption.

Key Changes

  1. New Metadata Endpoint (/v1/list/metadata)
  • Added new endpoint for combined app metadata
  • Takes a reference parameter to identify the app
  • Returns both icon and rich app metadata in a single response
  • Maintains backward compatibility with existing endpoints
  1. Core Implementation (internal/homepage/list_apps.go)
  • Implemented AppMeta struct for rich application data
  • Added caching mechanism with periodic updates
  • Created GetAppInfo function that combines:
    • Icon metadata from existing system
    • Rich app metadata from selfhst/apps
  1. Configuration and Initialization
  • Added cache configuration in constants.go
  • Integrated initialization in main.go
  • Implemented proper error handling and logging

Benefits

  1. Backward Compatibility

    • Existing icon system remains untouched
    • All current functionality continues to work as before
    • No risk of breaking existing features

  2. Performance Optimization

    • Frontend can use lightweight icon endpoint for basic display
    • Rich metadata only fetched when needed
    • Reduced payload size for basic UI elements

  3. Flexible Integration

    • Developer can gradually adopt the new system
    • Option to use either endpoint based on needs
    • Clear path for future migration if desired

Commit Structure

  1. feat(api): add new metadata endpoint for combined app information
  2. feat(api): register metadata endpoint in API handler
  3. feat(homepage): implement app metadata system with caching
  4. feat(config): add app metadata cache configuration and initialization

Testing

The test suite (list_apps_test.go) covers:

  • Basic app metadata parsing and validation
  • Integration with icon system
  • Different data availability scenarios:
    • Both icon and app data available
    • Only app data available
    • Only icon data available
    • No data available
  • HTTP response mocking for testing

Next Steps

  1. Review the implementation for any potential improvements
  2. Consider adding documentation for the new endpoint
  3. Plan frontend integration strategy
@dacagi commented on GitHub (Jun 12, 2025): As already mentioned I'm not well versed in Go, but since we now have AI to help us, I decided to try and see what I could achieve today. I won't open a PR unless you tell me to do so, I have limited trust in AI agents. Since it was me who proposed the changes I wanted to help as much as possible. Please review my [feat/app-metadata](https://github.com/dacagi/godoxy/tree/feat/app-metadata) branch and let me know if this is even helpful. Do not hesitate to discard if useless. ## App Metadata Integration Summary Implemented a new metadata system that provides rich application information while maintaining backward compatibility with the existing icon system. The implementation tries to follow a clean separation of concerns and allows for gradual adoption. ### Key Changes 1. **New Metadata Endpoint (`/v1/list/metadata`)** - Added new endpoint for combined app metadata - Takes a `reference` parameter to identify the app - Returns both icon and rich app metadata in a single response - Maintains backward compatibility with existing endpoints 2. **Core Implementation (`internal/homepage/list_apps.go`)** - Implemented `AppMeta` struct for rich application data - Added caching mechanism with periodic updates - Created `GetAppInfo` function that combines: - Icon metadata from existing system - Rich app metadata from selfhst/apps 3. **Configuration and Initialization** - Added cache configuration in `constants.go` - Integrated initialization in `main.go` - Implemented proper error handling and logging ### Benefits 1. **Backward Compatibility** - Existing icon system remains untouched - All current functionality continues to work as before - No risk of breaking existing features 2. **Performance Optimization** - Frontend can use lightweight icon endpoint for basic display - Rich metadata only fetched when needed - Reduced payload size for basic UI elements 3. **Flexible Integration** - Developer can gradually adopt the new system - Option to use either endpoint based on needs - Clear path for future migration if desired ### Commit Structure 1. `feat(api): add new metadata endpoint for combined app information` 2. `feat(api): register metadata endpoint in API handler` 3. `feat(homepage): implement app metadata system with caching` 4. `feat(config): add app metadata cache configuration and initialization` ### Testing The test suite (`list_apps_test.go`) covers: - Basic app metadata parsing and validation - Integration with icon system - Different data availability scenarios: - Both icon and app data available - Only app data available - Only icon data available - No data available - HTTP response mocking for testing ### Next Steps 1. Review the implementation for any potential improvements 2. Consider adding documentation for the new endpoint 3. Plan frontend integration strategy
adam commented 2025-12-29 14:24:37 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Jun 12, 2025):

Thanks for implementing the feature. Have had a slight peek, I think it would be useful. Will pull your branch directly and edit with interactive rebase.

@yusing commented on GitHub (Jun 12, 2025): Thanks for implementing the feature. Have had a slight peek, I think it would be useful. Will pull your branch directly and edit with interactive rebase.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
pull-request
Mirrored from GitHub Pull Request
 wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/godoxy-yusing#87
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?