vsund

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

  https://www.youtube.com/feeds/videos.xml?channel_id=<account_id>
  https://www.youtube.com/feeds/videos.xml?user=<account_name>

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?

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.

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.

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?

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.

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 :)