docs: update README.md, logo, etc... #269

koru commented 2026年04月18日 15:21:51 +02:00

Related: #265

Just small docs update.

Related: https://codeberg.org/celenity/Phoenix/issues/265 Just small docs update.

koru commented 2026年04月19日 07:33:04 +02:00

I agree that using remote assets in the README.md isn't the best idea from a privacy standpoint, but originally, the goal was to gather statistics independently of the forge platforms. That said, I don't think it's particularly necessary at the moment.

I agree that using remote assets in the README.md isn't the best idea from a privacy standpoint, but originally, the goal was to gather statistics independently of the forge platforms. That said, I don't think it's particularly necessary at the moment.

celenity commented 2026年04月19日 08:19:31 +02:00

@ivankopylov6603 wrote in #269 (comment):

the goal was to gather statistics independently of the forge platforms

That's fair, and it would indeed be nice (I do like the display of those statistics) - but ultimately I think we always have to put the privacy and security of users above everything else. Ideally, I wish there was some way we could make these embeds click-to-load - so that we could kepe the embeds, but users would be in full control over whether they wish to make these connections to external parties.

Maybe, at some point, we could consider making some kind of separate page/document for the statistics like this? We could then add a link to/banner for it on the README (while warning it will connect to third-parties like repology.org and shields.io). It wouldn't be as clean or ideal/convenient, but might be a decent balance/compromise.

If we did that approach, then if we wanted to, we could maybe even add static versions of the embeds/banners that just link to the relevant part of the separate statistics page?

IDK, these are just some thoughts I'm having/throwing out there.

@ivankopylov6603 wrote in https://codeberg.org/celenity/Phoenix/pulls/269#issuecomment-13339464: > the goal was to gather statistics independently of the forge platforms That's fair, and it would indeed be nice *(I do like the display of those statistics)* - but ultimately I think we always have to put the privacy and security of users above everything else. Ideally, I wish there was some way we could make these embeds click-to-load - so that we could kepe the embeds, but users would be in full control over whether they wish to make these connections to external parties. Maybe, at some point, we could consider making some kind of separate page/document for the statistics like this? We could then add a link to/banner for it on the README *(while warning it will connect to third-parties like `repology.org` and `shields.io`)*. It wouldn't be as clean or ideal/convenient, but might be a decent balance/compromise. If we did that approach, then if we wanted to, we could maybe even add static versions of the embeds/banners that just link to the relevant part of the separate statistics page? IDK, these are just some thoughts I'm having/throwing out there.

koru commented 2026年04月19日 08:52:06 +02:00

@celenity wrote in #269 (comment):

@ivankopylov6603 wrote in #269 (comment):

the goal was to gather statistics independently of the forge platforms

That's fair, and it would indeed be nice (I do like the display of those statistics) - but ultimately I think we always have to put the privacy and security of users above everything else. Ideally, I wish there was some way we could make these embeds click-to-load - so that we could kepe the embeds, but users would be in full control over whether they wish to make these connections to external parties.

Maybe, at some point, we could consider making some kind of separate page/document for the statistics like this? We could then add a link to/banner for it on the README (while warning it will connect to third-parties like repology.org and shields.io). It wouldn't be as clean or ideal/convenient, but might be a decent balance/compromise.

If we did that approach, then if we wanted to, we could maybe even add static versions of the embeds/banners that just link to the relevant part of the separate statistics page?

IDK, these are just some thoughts I'm having/throwing out there.

Actually, we could implement statistics using several different approaches:

• A Shell or Python script that generates .svg elements by fetching values from the platforms' APIs, or from something like shields.io, every couple of days. However, this would require either manual updates or a CI/CD actions.
• A separate .md page for stats, but then again, that somewhat defeats the purpose of having visible, at-a-glance statistics.
• Proxying requests to shields.io through our own server, but that still involves contacting an external server, which raises privacy concerns.
• Using a click-to-load element in the .md file via <iframe>, but this also requires a proxy, and wrapping it in <details> doesn't prevent browsers from caching the content.
• Or, we could simply maintain the statistics in a Markdown table and update it manually.

I think we could consider the first and last options.

@celenity wrote in https://codeberg.org/celenity/Phoenix/pulls/269#issuecomment-13340148: > @ivankopylov6603 wrote in #269 (comment): > > > the goal was to gather statistics independently of the forge platforms > > That's fair, and it would indeed be nice _(I do like the display of those statistics)_ - but ultimately I think we always have to put the privacy and security of users above everything else. Ideally, I wish there was some way we could make these embeds click-to-load - so that we could kepe the embeds, but users would be in full control over whether they wish to make these connections to external parties. > > Maybe, at some point, we could consider making some kind of separate page/document for the statistics like this? We could then add a link to/banner for it on the README _(while warning it will connect to third-parties like `repology.org` and `shields.io`)_. It wouldn't be as clean or ideal/convenient, but might be a decent balance/compromise. > > If we did that approach, then if we wanted to, we could maybe even add static versions of the embeds/banners that just link to the relevant part of the separate statistics page? > > IDK, these are just some thoughts I'm having/throwing out there. Actually, we could implement statistics using several different approaches: - A Shell or Python script that generates `.svg` elements by fetching values from the platforms' APIs, or from something like shields.io, every couple of days. However, this would require either manual updates or a CI/CD actions. - A separate `.md` page for stats, but then again, that somewhat defeats the purpose of having visible, at-a-glance statistics. - Proxying requests to `shields.io` through our own server, but that still involves contacting an external server, which raises privacy concerns. - Using a click-to-load element in the `.md` file via `<iframe>`, but this also requires a proxy, and wrapping it in `<details>` doesn't prevent browsers from caching the content. - Or, we could simply maintain the statistics in a Markdown table and update it manually. I think we could consider the first and last options.

celenity commented 2026年04月20日 00:32:10 +02:00

@ivankopylov6603 wrote in #269 (comment):

@celenity wrote in #269 (comment):

@ivankopylov6603 wrote in #269 (comment):

the goal was to gather statistics independently of the forge platforms

That's fair, and it would indeed be nice (I do like the display of those statistics) - but ultimately I think we always have to put the privacy and security of users above everything else. Ideally, I wish there was some way we could make these embeds click-to-load - so that we could kepe the embeds, but users would be in full control over whether they wish to make these connections to external parties.
Maybe, at some point, we could consider making some kind of separate page/document for the statistics like this? We could then add a link to/banner for it on the README (while warning it will connect to third-parties like repology.org and shields.io). It wouldn't be as clean or ideal/convenient, but might be a decent balance/compromise.
If we did that approach, then if we wanted to, we could maybe even add static versions of the embeds/banners that just link to the relevant part of the separate statistics page?
IDK, these are just some thoughts I'm having/throwing out there.

Actually, we could implement statistics using several different approaches:

* A Shell or Python script that generates `.svg` elements by fetching values from the platforms' APIs, or from something like shields.io, every couple of days. However, this would require either manual updates or a CI/CD actions.
* A separate `.md` page for stats, but then again, that somewhat defeats the purpose of having visible, at-a-glance statistics.
* Proxying requests to `shields.io` through our own server, but that still involves contacting an external server, which raises privacy concerns.
* Using a click-to-load element in the `.md` file via `<iframe>`, but this also requires a proxy, and wrapping it in `<details>` doesn't prevent browsers from caching the content.
* Or, we could simply maintain the statistics in a Markdown table and update it manually.

I think we could consider the first and last options.

Interesting, both your first and last options sound plausible to me as well.

But, I do agree with your point earlier:

That said, I don't think it's particularly necessary at the moment.

So I'll go ahead and merge this (since you made your recent changes taking care of the embeds), and we can revisit this later if/as needed.

Thanks again for all your work here (and contributions lately in general)! Very much appreciated.

@ivankopylov6603 wrote in https://codeberg.org/celenity/Phoenix/pulls/269#issuecomment-13340562: > @celenity wrote in #269 (comment): > > > @ivankopylov6603 wrote in #269 (comment): > > > the goal was to gather statistics independently of the forge platforms > > > > > > That's fair, and it would indeed be nice _(I do like the display of those statistics)_ - but ultimately I think we always have to put the privacy and security of users above everything else. Ideally, I wish there was some way we could make these embeds click-to-load - so that we could kepe the embeds, but users would be in full control over whether they wish to make these connections to external parties. > > Maybe, at some point, we could consider making some kind of separate page/document for the statistics like this? We could then add a link to/banner for it on the README _(while warning it will connect to third-parties like `repology.org` and `shields.io`)_. It wouldn't be as clean or ideal/convenient, but might be a decent balance/compromise. > > If we did that approach, then if we wanted to, we could maybe even add static versions of the embeds/banners that just link to the relevant part of the separate statistics page? > > IDK, these are just some thoughts I'm having/throwing out there. > > Actually, we could implement statistics using several different approaches: > > * A Shell or Python script that generates `.svg` elements by fetching values from the platforms' APIs, or from something like shields.io, every couple of days. However, this would require either manual updates or a CI/CD actions. > > * A separate `.md` page for stats, but then again, that somewhat defeats the purpose of having visible, at-a-glance statistics. > > * Proxying requests to `shields.io` through our own server, but that still involves contacting an external server, which raises privacy concerns. > > * Using a click-to-load element in the `.md` file via `<iframe>`, but this also requires a proxy, and wrapping it in `<details>` doesn't prevent browsers from caching the content. > > * Or, we could simply maintain the statistics in a Markdown table and update it manually. > > > I think we could consider the first and last options. Interesting, both your first and last options sound plausible to me as well. But, I do agree with your point earlier: > That said, I don't think it's particularly necessary at the moment. So I'll go ahead and merge this *(since you made your recent changes taking care of the embeds)*, and we can revisit this later if/as needed. Thanks again for all your work here *(and contributions lately in general)*! Very much appreciated.