I assume you mean the settings within the instance (or more accurately, your session) of Invidious states that it proxies the activity. However, if you're just referring to Invidious itself, this is a setting that can be enabled/disabled for the entire Invidious instance. The instance's default setting could also be disabled even if the instance supports proxying. Regardless, you could verify Invidious is proxying everything by reviewing the networking tab of your browser's developer tools to confirm that all traffic is with your Invidious instance.
Given everything you said, it sounds like any recommendations you receive within Invidious is most likely due to the collective activity of all users on that Invidious instance. Additionally, any recommendations you receive directly on YouTube is likely from other information YouTube collected about you (not your Invidious activity).
While I cannot definitely confirm that this has absolutely nothing to do with Framework, I cannot imagine anyone knowledgeable about this arguing in good faith that Framework is complicity and secretly acting to violate your privacy.
There are no "official" or "trusted" instances. The instances listed on Invidious' site meet (or should meet) a certain set of criteria. Several of those items could be considered bare minimum for hosting any website over 10 years ago (eg: be served via https, must have a domain) or are about other availability metrics. I'm not saying you shouldn't trust any of those instances, but just want to clarify that it doesn't necessarily mean that the instances are endorsed or trusted by the Invidious team. Instead, it is just a directory of instances that meet some minimum criteria.
I didn't check all of the instances currently on the list, but instances that were previously on the list did not proxy all traffic from YouTube. Since this is not an requirement to be included on Invidious' list of instances, I assume that there are likely one or more instance that is not proxying the YouTube traffic.
If the traffic is not proxies, then your browser will interact directly with YouTube's servers for some content (typically the actual video content). While this prevents you from interacting with YouTube's frontend (and all the tracking that comes with that), it does not prevent YouTube from identifying which videos were served to your IP address, which parts of the video were requested, or other identifying information.
Invidious is more private than using YouTube directly or even most other 3rd party services, but it may not completely prevent Google from tracking you depending on it's hosting, configuration, and usage.
Are you running the Invidious instance yourself?
If so, are you running it on a VPN?
Are you the only user on this Invidious instance?
Is Invidious proxying all activity?
Is the Invidious instance outdated, customized, or noticeably different from most other instances?
Do you click on links from comments or video descriptions?
Do you first obtain YouTube links or video IDs and then convert them to an Invidious link?
Are you watching videos with little traffic or videos that are private?
There is also the possibility that Invidious makes the recommendations itself, independently of YouTube. Clearing Invidious cookies and all site data should mitigate this, but if you are signing into Invidious then doing that won't accomplish much.
Additionally, Invidious may make the recommendations based on all its users' activity. If you're using an instance with little activity then the recommendations may be more heavily skewed to your activity. There's also the possibility that other users of your Invidous instance share interests with you.
Lastly, it is also possible that YouTube's recommendations are based on unrelated factors.
YouTube may be recommending videos because they are genuinely popular or are trending in your area.
YouTube may be recommending videos based on other users' YouTube activity on your IP address.
YouTube may be recommending videos based on other internet traffic YouTube/Google/Alphabet has associated with your account, fingerprint, or IP address.
All of this, including several other possibilities not mentioned, is far more likely than Framework shipping a hardware/firmware backdoor that hasn't been caught yet which allows Framework to monitor your Invidious acitivity so Framework can sell/share your data back to YouTube. This is a very niche use case that would be extremely expensive, difficult, and risky for Framework (or any other computer manufacturer) to accomplish. Any money Framework makes from this would likely not even cover the cost to do this.
The Framework "backdoor" that you heard about is likely the data breach that recently impacted Framework. This data breach occurred due to a phishing attack on an employee of the accounting firm contracted by Framework.
I generally agree with this. Unless OpenAI has a track record of being poor stewards of open source projects, then right now the concern is mostly FUD.
However, this is a bit aggressive. It is appropriate to be skeptical about the intent of a controversial company acquiring another company that made a few popular open source projects or of the future state of those open source projects.
Just because a popular open source project is well liked today doesn't mean the community will be happy with the project in the future or even that the project will forever remain open source. Some notable recent examples include Redis, Terraform, and CentOS.
That's correct, but the XMPP portion of this communication chain is just your device to the JMP service. Any messages sent or received to another phone number are delivered via SMS/MMS. As a result, those messages can be read by unrelated 3rd parties. I assume something similar is possible for voice calls as well (or at the very least the call start/stop times and the other number on the call can be determined).
Essentially this just shifts trust from a mobile phone carrier to JMP. However, I understand that it may be more challenging to hack a VOIP number than perform a SIM swap attack. Another benefit of JMP for privacy is the more challenging tracking of location for a JMP phone number.
I'm not saying that using JMP is bad. I am saying if you need a secure and private way of messaging someone then this is not the best solution.
It depends on what your threat model is. For example, do you want to mitigate the ability to easily link accounts and other information to you based on a single phone number? If so, then this will help with that assuming you (at least temporarily) use multiple numbers through JMP. On the other hand, if you want your communication to be private then there are better alternatives.
Ultimately, this is similar to using a privacy respecting email provider over gmail. Unless you take some additional precautions, your communications have a similar security/privacy exposure. It can be an improvement (assuming you trust JMP), but it is not the best means of communication in terms of privacy.
I see there are a few performance comparisons, but I wonder how this compares to ty. I guess it may be a while before we can really compare the two since they're both in alpha/beta.
Maybe I'm not picking up on the different models correctly, but the first link I sent was about Z-Wave.
Can I use the Assure Lock 2 with my Z-Wave Hub?
The Assure Lock 2 supports the following Z-Wave modules:
Z-Wave 500 Series (version 1.8.1)
Module Part Number: AYR-MOD-ZW2-USA
Z-Wave 700 Series (available at a later date)
I know some people, like yourself and the commenter thelordzer0, have had success using the lock without a Yale account or app. I'm not sure why you've been able to but others are reporting differently. I was just commenting to help OP out in case they're one of the other people who were forced to create an account and/or use the Yale app to initialize their lock.
I've seen multiple reports online about the lock requiring an account though and Yale's documentation stating that it only supports 500 series. Below are just a few examples of reports indicating that a Yale account is required for setup. Is yours the same model?
This lock requires a Yale account to register/setup the lock though, correct? In other words, while you can use the lock locally, it first needs to be associated with a Yale account.
Additionally, if I remember correctly, its Z-Wave module is a 500 series using the Security 0 (S0) standard instead of the more modern 800 series and/or Security 2 (S2) sandard. The 800 series (introduced in 2021) should provide much better reliability and range while the S2 standard (introduced in 2017) should make your connection more secure and less chatty. However, the 800 series does not operate as a mesh network and is still working through the final legislative approvals in Europe.
Unfortunately, I don't think there is a one-size-fits-all, perfect solution. I believe the only Z-Wave lock that addresses the two items in my comment is the Philips 4000 Series deadbolt. One issue with that lock is I believe you have less control over the combinations without the Philips app (eg: cannot specify date/time ranges when a code will work, can only add codes while physically at the device, etc.).
I'm not too sure - I'm not too familiar with any of these services (including PinePods 😂). I know this type of feature is a common request for any audio related services though. I imagine that this is something that could be added at some point, but I'm not sure what the effort would be.
I don't see anything about it on the roadmap for v1 or anywhere else on Pinepods' issues. Perhaps the developer/maintainer @madeofpendletonwool@lemmy.world can chime in or an issue on Github can be created with more information about this feature request?
Single service for all your podcasting needs (ie: searching, storing, playing, tracking, and syncing podcasts + listening history)
Multi-device, cross-platform support (I know this can be somewhat accomplished through the process that you mentioned, but you would need separate apps for iOS and desktop/web)
(speculation/assumption) It may be easier to get newer features added to Pinepods (especially those that you or the community contributes and/or for server-related features) since the project is focused on just podcasts
I'm not aware of a similar all-in-one podcast server + client service. As Pinepods matures, it can offer features/services that may not be easily included in the services you mentioned. For example, searching by transcript across all downloaded podcasts or summarizing/combining multiple podcasts (which may be helpful if you listen to multiple daily/weekly/monthly "news" podcasts of a similar topic).
Supporting a newer project and open source community
The first two may not apply to you in particular, but I'm sure if you have other users that use the services you support then I'm sure they would appreciate having to learn/use a single app/interface for podcasts instead of having to learn one for searching/downloading (if they care about that at all), one for listening on mobile, one for listening on web, and another for managing their download/play sync.
Lots of good suggestions in this thread! A few additional ones that I don't think I've seen yet:
Testing/QA server (eg: test existing software's major upgrades before upgrading your "production" environment, test new services without impacting your "production" environment, test new operating systems/virtualization software/etc.)
Learn automation (eg: Terraform, Opentofu, Ansible, etc.) or horizontal scaling (eg: Docker Swarm, Kubernetes, etc.) to try improving future upgrades and/or high availability
Media center PCs (eg: Kodi, LibreElec, OSMC, etc.) or gaming PCs for various TVs around your house to replace Apple TVs/Google TVs/etc. or gaming consoles
I recommend that you think hard and properly access your threat profile. You are likely going to have to pay with either your wallet (eg: some sort of company incorporation, lawyer fees, forwarding services, and other privacy protection services), your time (eg: using "inconvenient" services, managing separate accounts, etc.), or both. It can be draining (in more than one way) and take away some of the joy that you're intending this to bring you if you do too much to protect yourself. On the other hand, if you do too little then you can overexpose yourself leading to pricey or dangerous situations.
At a minimum, I would recommend incorpating and making sure your name is not publicly tied to the company in any way. You will likely need a person/company/lawyer to be publicly listed as an agent of some sort for the company. You should be able to have someone do this for you for a small-medium sized fee. Once you have that, do everything in the company's name and ideally with separate phone numbers, email addresses, online accounts, bank accounts, and physical addresses as anything tied directly to you.
Some of that is to protect yourself financially and legally, but there are some obvious privacy benefits as well. Anything beyond that should be dictated by your threat profile.
As always though, follow best practices when it comes to security! Use strong passwords and use multi-factor authentication when possible (or ideally, use passkeys). Don't reuse passwords (and ideally, don't reuse email addresses for multiple accounts). Avoid clicking links in messages when possible. Don't open suspicious documents (especially if they are unexpected). Verify the authenticity of any new person/business you interact with (especially if they contact you first). Be vigilant of all forms of phishing attacks.
Another piece of advice (that you didn't ask for, sorry!) - if the process of making art is the thing that brings you joy and the materials are not too expenses, then just focus on making the art without selling it (at least for a while). At worst, you will realize that maybe this isn't as enjoyable as you thought it would be with the added benefit of not needing to deal with all the troubles of working through all the legal/financial/privacy protections. At best, if you decide to get serious about selling it then you'll have a larger product inventory and better understanding of what you like making most. It may also help you understand what you should price everything at (assuming you've made some of the items in larger quantities).
Sorry to hear about the frustrations regarsing F-Droid, but glad to hear it will at least be on IzzyOnDroid. Excited to check it out once it's available on there!
Excited to see the app develop over time. I bet Pinepods will be able to meet all my podcasting needs sooner than I can imagine.
Thanks for the update! Really appreciate all of the work that has gone into this.
A few quick questions:
Will the Android app be available on F-Droid? It looks like it should/will be, but I don't see it on F-Droid at the moment.
Is it possible to download episodes from a Pinepods server to a local device via a Pinepods client so the episodes can be stored on something externally, like a USB drive or old MP3 player? If so, can all/multiple episodes on the server for a podcast be downloaded without having to manually select each episode? The only download options that I have seen are for the server to download the episodes from the podcast's source.
I believe Google plans to use Google Play Services to block side loaded apps. By default, GrapheneOS does not come with Google Play Services installed. I am not sure how things would work if the sandboxes version of Google Play Services that GrapheneOS provides is installed.
The issue about maintaining/updating GrapheneOS is a separate issue from side loading apps. That was due to Google shifting the development of Android to a closed source model and only open sourcing the final code. This limits the Grapheme team's ability to anticipate changes and make any required adjustments until after the release of Android.
Not sure if this is what @ocean@lemmy.selfhostcat.com was referring to, but I found free-games-claimer from a quick search which seems similar and has a container image at ghcr.io/vogler/free-games-claimer.
I think that any guides you find for Gitea + Renovate should work still for Forgejo + Renovate.
I believe the process is:
Create Forgejo instance
Create a user for Renovate within Forgejo
Using the CLI on your local machine (or another tool to complete this step), create an SSH public/private key for the Renovate user
Log into Forgejo using the Renovate user and configure the previously created SSH keys and separately generate a Forgejo token
Create a Renovate instance with settings for at least RENOVATE_GIT_PRIVATE_KEY (SSH private key value), RENOVATE_TOKEN (Forgejo token value), RENOVATE_PLATFORM (gitea), RENOVATE_ENDPOINT (Forgejo API base URL), and any other Renovate settings that you may find helpful/necessary to configure (eg: GITHUB_COM_TOKEN, RENOVATE_AUTODISCOVER, etc.)
Depending on how you want things to work, you may need to give the Renovate Forgejo user access to individual repos
I assume you mean the settings within the instance (or more accurately, your session) of Invidious states that it proxies the activity. However, if you're just referring to Invidious itself, this is a setting that can be enabled/disabled for the entire Invidious instance. The instance's default setting could also be disabled even if the instance supports proxying. Regardless, you could verify Invidious is proxying everything by reviewing the networking tab of your browser's developer tools to confirm that all traffic is with your Invidious instance.
Given everything you said, it sounds like any recommendations you receive within Invidious is most likely due to the collective activity of all users on that Invidious instance. Additionally, any recommendations you receive directly on YouTube is likely from other information YouTube collected about you (not your Invidious activity).
While I cannot definitely confirm that this has absolutely nothing to do with Framework, I cannot imagine anyone knowledgeable about this arguing in good faith that Framework is complicity and secretly acting to violate your privacy.
There are no "official" or "trusted" instances. The instances listed on Invidious' site meet (or should meet) a certain set of criteria. Several of those items could be considered bare minimum for hosting any website over 10 years ago (eg: be served via https, must have a domain) or are about other availability metrics. I'm not saying you shouldn't trust any of those instances, but just want to clarify that it doesn't necessarily mean that the instances are endorsed or trusted by the Invidious team. Instead, it is just a directory of instances that meet some minimum criteria.
I didn't check all of the instances currently on the list, but instances that were previously on the list did not proxy all traffic from YouTube. Since this is not an requirement to be included on Invidious' list of instances, I assume that there are likely one or more instance that is not proxying the YouTube traffic.
If the traffic is not proxies, then your browser will interact directly with YouTube's servers for some content (typically the actual video content). While this prevents you from interacting with YouTube's frontend (and all the tracking that comes with that), it does not prevent YouTube from identifying which videos were served to your IP address, which parts of the video were requested, or other identifying information.
Invidious is more private than using YouTube directly or even most other 3rd party services, but it may not completely prevent Google from tracking you depending on it's hosting, configuration, and usage.
There is also the possibility that Invidious makes the recommendations itself, independently of YouTube. Clearing Invidious cookies and all site data should mitigate this, but if you are signing into Invidious then doing that won't accomplish much.
Additionally, Invidious may make the recommendations based on all its users' activity. If you're using an instance with little activity then the recommendations may be more heavily skewed to your activity. There's also the possibility that other users of your Invidous instance share interests with you.
Lastly, it is also possible that YouTube's recommendations are based on unrelated factors.
All of this, including several other possibilities not mentioned, is far more likely than Framework shipping a hardware/firmware backdoor that hasn't been caught yet which allows Framework to monitor your Invidious acitivity so Framework can sell/share your data back to YouTube. This is a very niche use case that would be extremely expensive, difficult, and risky for Framework (or any other computer manufacturer) to accomplish. Any money Framework makes from this would likely not even cover the cost to do this.
The Framework "backdoor" that you heard about is likely the data breach that recently impacted Framework. This data breach occurred due to a phishing attack on an employee of the accounting firm contracted by Framework.
I generally agree with this. Unless OpenAI has a track record of being poor stewards of open source projects, then right now the concern is mostly FUD.
However, this is a bit aggressive. It is appropriate to be skeptical about the intent of a controversial company acquiring another company that made a few popular open source projects or of the future state of those open source projects.
Just because a popular open source project is well liked today doesn't mean the community will be happy with the project in the future or even that the project will forever remain open source. Some notable recent examples include Redis, Terraform, and CentOS.
That's correct, but the XMPP portion of this communication chain is just your device to the JMP service. Any messages sent or received to another phone number are delivered via SMS/MMS. As a result, those messages can be read by unrelated 3rd parties. I assume something similar is possible for voice calls as well (or at the very least the call start/stop times and the other number on the call can be determined).
Essentially this just shifts trust from a mobile phone carrier to JMP. However, I understand that it may be more challenging to hack a VOIP number than perform a SIM swap attack. Another benefit of JMP for privacy is the more challenging tracking of location for a JMP phone number.
I'm not saying that using JMP is bad. I am saying if you need a secure and private way of messaging someone then this is not the best solution.
It depends on what your threat model is. For example, do you want to mitigate the ability to easily link accounts and other information to you based on a single phone number? If so, then this will help with that assuming you (at least temporarily) use multiple numbers through JMP. On the other hand, if you want your communication to be private then there are better alternatives.
Ultimately, this is similar to using a privacy respecting email provider over gmail. Unless you take some additional precautions, your communications have a similar security/privacy exposure. It can be an improvement (assuming you trust JMP), but it is not the best means of communication in terms of privacy.
I see there are a few performance comparisons, but I wonder how this compares to ty. I guess it may be a while before we can really compare the two since they're both in alpha/beta.
Maybe I'm not picking up on the different models correctly, but the first link I sent was about Z-Wave.
I know some people, like yourself and the commenter thelordzer0, have had success using the lock without a Yale account or app. I'm not sure why you've been able to but others are reporting differently. I was just commenting to help OP out in case they're one of the other people who were forced to create an account and/or use the Yale app to initialize their lock.
Ah, you're right about 800 mesh and LR.
I've seen multiple reports online about the lock requiring an account though and Yale's documentation stating that it only supports 500 series. Below are just a few examples of reports indicating that a Yale account is required for setup. Is yours the same model?
This lock requires a Yale account to register/setup the lock though, correct? In other words, while you can use the lock locally, it first needs to be associated with a Yale account.
Additionally, if I remember correctly, its Z-Wave module is a 500 series using the Security 0 (S0) standard instead of the more modern 800 series and/or Security 2 (S2) sandard. The 800 series (introduced in 2021) should provide much better reliability and range while the S2 standard (introduced in 2017) should make your connection more secure and less chatty. However, the 800 series does not operate as a mesh network and is still working through the final legislative approvals in Europe.
Unfortunately, I don't think there is a one-size-fits-all, perfect solution. I believe the only Z-Wave lock that addresses the two items in my comment is the Philips 4000 Series deadbolt. One issue with that lock is I believe you have less control over the combinations without the Philips app (eg: cannot specify date/time ranges when a code will work, can only add codes while physically at the device, etc.).
I'm not too sure - I'm not too familiar with any of these services (including PinePods 😂). I know this type of feature is a common request for any audio related services though. I imagine that this is something that could be added at some point, but I'm not sure what the effort would be.
I don't see anything about it on the roadmap for v1 or anywhere else on Pinepods' issues. Perhaps the developer/maintainer @madeofpendletonwool@lemmy.world can chime in or an issue on Github can be created with more information about this feature request?
The biggest benefits are likely:
The first two may not apply to you in particular, but I'm sure if you have other users that use the services you support then I'm sure they would appreciate having to learn/use a single app/interface for podcasts instead of having to learn one for searching/downloading (if they care about that at all), one for listening on mobile, one for listening on web, and another for managing their download/play sync.
Lots of good suggestions in this thread! A few additional ones that I don't think I've seen yet:
I recommend that you think hard and properly access your threat profile. You are likely going to have to pay with either your wallet (eg: some sort of company incorporation, lawyer fees, forwarding services, and other privacy protection services), your time (eg: using "inconvenient" services, managing separate accounts, etc.), or both. It can be draining (in more than one way) and take away some of the joy that you're intending this to bring you if you do too much to protect yourself. On the other hand, if you do too little then you can overexpose yourself leading to pricey or dangerous situations.
At a minimum, I would recommend incorpating and making sure your name is not publicly tied to the company in any way. You will likely need a person/company/lawyer to be publicly listed as an agent of some sort for the company. You should be able to have someone do this for you for a small-medium sized fee. Once you have that, do everything in the company's name and ideally with separate phone numbers, email addresses, online accounts, bank accounts, and physical addresses as anything tied directly to you.
Some of that is to protect yourself financially and legally, but there are some obvious privacy benefits as well. Anything beyond that should be dictated by your threat profile.
As always though, follow best practices when it comes to security! Use strong passwords and use multi-factor authentication when possible (or ideally, use passkeys). Don't reuse passwords (and ideally, don't reuse email addresses for multiple accounts). Avoid clicking links in messages when possible. Don't open suspicious documents (especially if they are unexpected). Verify the authenticity of any new person/business you interact with (especially if they contact you first). Be vigilant of all forms of phishing attacks.
Another piece of advice (that you didn't ask for, sorry!) - if the process of making art is the thing that brings you joy and the materials are not too expenses, then just focus on making the art without selling it (at least for a while). At worst, you will realize that maybe this isn't as enjoyable as you thought it would be with the added benefit of not needing to deal with all the troubles of working through all the legal/financial/privacy protections. At best, if you decide to get serious about selling it then you'll have a larger product inventory and better understanding of what you like making most. It may also help you understand what you should price everything at (assuming you've made some of the items in larger quantities).
Thanks for the response!
Sorry to hear about the frustrations regarsing F-Droid, but glad to hear it will at least be on IzzyOnDroid. Excited to check it out once it's available on there!
Excited to see the app develop over time. I bet Pinepods will be able to meet all my podcasting needs sooner than I can imagine.
Thanks for the update! Really appreciate all of the work that has gone into this.
A few quick questions:
I believe Google plans to use Google Play Services to block side loaded apps. By default, GrapheneOS does not come with Google Play Services installed. I am not sure how things would work if the sandboxes version of Google Play Services that GrapheneOS provides is installed.
The issue about maintaining/updating GrapheneOS is a separate issue from side loading apps. That was due to Google shifting the development of Android to a closed source model and only open sourcing the final code. This limits the Grapheme team's ability to anticipate changes and make any required adjustments until after the release of Android.
Not sure if this is what @ocean@lemmy.selfhostcat.com was referring to, but I found free-games-claimer from a quick search which seems similar and has a container image at
ghcr.io/vogler/free-games-claimer.I think that any guides you find for Gitea + Renovate should work still for Forgejo + Renovate.
I believe the process is:
RENOVATE_GIT_PRIVATE_KEY(SSH private key value),RENOVATE_TOKEN(Forgejo token value),RENOVATE_PLATFORM(gitea),RENOVATE_ENDPOINT(Forgejo API base URL), and any other Renovate settings that you may find helpful/necessary to configure (eg:GITHUB_COM_TOKEN,RENOVATE_AUTODISCOVER, etc.)uv
It is made by the Astral team, who made ruff and are working on a static type checker. They're making great Python tooling and uv is no exception.