This is exactly what I don't understand about all the feed readers out there.
It seems so obvious that the next step for feed readers would be social interactions like sharing, also it would be to easy to add I guess.
Additionally the aspect of consuming YouTube via RSS feed. Feed readers could simply add small logic which transforms a given YouTube account into one of
And so on for similar services. RSS has such great potential but somehow nobody uses all of it.
Is there anything I miss? Why don't feed readers support external services (like the YouTube example from above)? Why don't feed readers add social features?
RSS is used by those who aren't into "social" addiction, but just want a quick listing of relevant news from a super-simple news feed (as in "really simple syndication"). A couple years ago Google embraced, extended and almost extinguished RSS, so I'm not sure RSS users are willing to obtain/share their feed URLs from a pointless central service; just go to the web sites you're reading frequently, check if they have an RSS feed announced in their HTML metadata (as indicated by an RSS symbol in eg. FF), and add the URL to your feeds.
Because RSS gives readers too much signal, and not enough noise (ads, profiling), and doesn't keep users within the walled garden ecosystems. That's why apps are popular, too. It is all about control. Another disadvantage is that RSS doesn't have native incremental updates, which increases data volume. Though that isn't very relevant in 2018.
As an RSS lover, I have zero interest in social features. If I occasionally want to share something, I can email/WhatsApp/Slack the URL; but for the most part I don't, and I'm able to read without the distraction and noise.
You can add the RSS feed of a youtube channel with the Tiny Tiny RSS bookmarklet, it's working for most channels, but not all for a reason I don't understand yet.
YouTube channel feeds, if they have one, are at: www.youtube.com/feeds/videos.xml?channel_id={channel_id} Some channels have a custom url and the id isn't obvious but it should be in the page source somewhere.
For example, "It's Okay To Be Smart" is at "www.youtube.com/user/itsokaytobesmart". Right click, view page source, search for "/channel/". That finds "<link rel="canonical" href="https://www.youtube.com/channel/UCH4BNI0-FOK2dMXoFtViWHw">". So the feed url is:
Woah, I spent more time than I care to admit trying to find some feeds. I thought I had the secret sauce all figured out :) https://www.youtube.com/feeds/videos.xml?user=itsokaytobesma... is much easier to use. I can think of a few channels where the play list thing will come in handy if it works. Gamers where I only want to see 1 out of 50 games they play and are who are orginized enough to keep seperate playlist is one example. You can't even do that with YouTubes own subscription method as far as I know.
There's a difference in certificate type. Let's encrypt (which only issues basic certificates) just verifies that you're the rightful owner of a domain, not whether the domain is what it says.
If you'd like to have more verification for your certificate you need a extended validation certificate (which often costs money). These certificates also include your (company) name and the issuer verifies whether it's correct or not.
Basic certificate issuers don't judge over domain names or content, they just verify domain ownership.
To clarify, other certificate types do not judge content either. The difference is that they verify your organisational details (to a varying degree, depending on the validation level) and include them in the certificate. The CA is not going to check whether the business is fraudulent or anything like that.
To clarify for people who've never bought one, an EV SSL cert actually involves work by humans at the CA. They do things like obtain copies of your state/provincial corporate registration, business license, LLC registration, local business license, etc. Then the do basic matching that your physical business address of record matches with what your state's Secretary of State has on file for your corporation. It's about a half hour process on the part of the CA of verifying the existence of a real business entity.
It uses Blockstack for the decentralized foundation it's built on. (Among other things) Blockstack stores your data on storage providers you connected to it (such as Google Drive, Dropbox, etc).
Both, Graphite and Blockstack, are fully open source. So there's nobody who will get in between you and your documents.
Storing an unencrypted file with a single storage provider is neither private nor secure. Blockstack allows users to select multiple storage providers, allowing for data replication and mitigation of any single source of failure. Additionally, encrypting a file client-side before it is stored means that Google or Dropbox or whoever can snoop all they want and not be able to see your data.
That's the conclusion I also came up with. It's pretty clear that the browser is the new platform for apps.
Though I wonder why Firefox OS has failed this hard. I never looked more into it, but isn't it a platform centered around having web apps as native apps? I think some day every OS will be similar, so was it ahead of time?
Here's @vsund, author of this commit message. I understand that the title may was a bit clickbaity and now the title got renamed to a more rational one (which is totally ok).
Unfortunately the new title "A JavaScript browser library fails due to an adblocker blacklisting 'beacon.js'" doesn't reflect the situation very well in my opinion. The library didn't fail (mainly because there is no library yet), what instead happened is that the adblocker blocked GitHub internal requests which resulted in a unusable repository.
The adblocker blocks requests that simply has "beacon.js" anywhere in the URL.
I see this rather as an issue of adblockers blocking to much than bad naming of projects :)
As one of an extremely large group of people who will never use that library but DO get protected from some ads and tracking by blacklisting beacon.js, I disagree that it's an issue with ad blockers.
The internet is a toxic place, to put it mildly, and if you're getting into any kind of public facing service on it, you need to know exactly what you're doing.
Wait, you're saying that a false positive in an ad blocker is _not_ an issue with the ad blocker? Of course it is! Blocking files based solely on their names is a brittle and error-prone way of doing things, and this false positive is a clear example of that.
For sure it's a false positive and I wish it didn't happen. But it does happen and there's no way I'm ditching my ad blocker just because of some small number of false positives.
I totally agree with you, but I think adblockers could do better than just block all requests that have "beacon.js" in it. But yeah, I definitely prefer many protected users about one working library :)
There are so many possibilities to block content, I'm sure that we could do better with protecting users against tracking while ensuring that less content gets blocked false-positive.
Additionally the aspect of consuming YouTube via RSS feed. Feed readers could simply add small logic which transforms a given YouTube account into one of
And so on for similar services. RSS has such great potential but somehow nobody uses all of it.Is there anything I miss? Why don't feed readers support external services (like the YouTube example from above)? Why don't feed readers add social features?