I've been using Ian's Secure Shoelace Knot for... years? I can't even remember how long, but it's served me very well. I just love how much more secure it is and how symmetrical and balanced the final result is. It's also such a trivial upgrade for kids that have learned to tie their shoes using the "bunny ear" method... just one extra twist.
I forgot to add a link to our recent announcement blog post to the project README. I've added that now, and I think it may help explain why we specifically built a service like this on top of Tailscale to take advantage of Magic DNS, automatically authenticated connections, etc. https://tailscale.com/blog/golink/
UX definitely ended up being one of the hardest parts. We also never got to the point of really building a compelling product on top of the protocols. We did actually do some work on privacy though, but it never got super far. For example, you could set simple access controls on content that was only available to friends that logged in with an OpenID. I think I had it so that certain of your hcard attributes were only included for authenticated users as well.
Some of the work we did then still exists today in various forms. Activity Steams led to Activity Pub, which has seen far more adoption than we ever did.
And microformats are still widely used in some communities, though certainly not like it could have been, largely things to Google putting weight behind schema.org. For example, nearly all of the indieweb.org work is based around microformats at the core, with things like webmention, micropub, etc
I apologize for the confusion this caused; that was certainly not the intent. Mea culpa! The name "libcrurl" was just an internal working name for this effort that wasn't expected to gain much attention.
This project is still very experimental in nature (as discussed at https://bugs.chromium.org/p/chromium/issues/detail?id=973603...), and there are no plans here to try and replace or compete with libcurl. We have huge respect for the tireless work Daniel does to maintain curl, and didn't mean to cause any confusion or extra work for him.
We currently only list project that are or were primarily developed by Google. We decided to include projects that started at Google and were since donated to foundations, such as Kubernetes.
But we aren't yet including projects where we are just heavy contributors, but they're not "Google projects". That includes Linux, git, LLVM, and a host of others. We do want to recognize them in our project directory, but want to make sure that they are distinguished from Google projects so that we're not implying something that is accurate.
> The default google approach to open source is unidirectional source dumps after all the work is done.
I can definitely say that is not our default approach to open source; in fact it's a very small minority of projects that actually operate in that fashion. However, I can understand that it could feel that way to some people.
We've long said and continue to believe that there is no one way to do open source. That's true of nearly every aspect of a project including licensing, governance, community management, etc. Project are released for different reasons, with different motivations and goals, and so the way they are managed often differs.
One area I know we could do better is to set better expectations for projects around many of these topics. How is the project managed, how are decisions made, how committed to this are we (ie. are we using it in production), etc? If those aspects of a given project were clearer, would that address some of your concern (with the understanding that some projects may be be held closer to the vest than others) ? Or are you objecting to the tighter control in general?
Could you expand on this a bit? We've tried to be very transparent with how we approach and think about open source by publishing all of our internal documentation at https://opensource.google.com/docs/. Is there something that's missing from that? Or are you thinking about certain specific projects being opaque in terms of how their managed?
Thanks. What you said definitely exemplifies the problem we were trying to solve. People often look through one or two of our GitHub organizations, but don't realize that we actually have over 100 of them. Plus many of our projects aren't actually on GitHub (or at least only mirrored to GitHub). The goal of this directory was to help discover those projects.
The problem is that we have over 2,000 projects, so simply listing them all on one page doesn't work very well. Hence why we built this directory, which allows browsing by category, by tag, by language, as well as full text search.
To clarify the timeline a little bit here... Rosehub wasn't actually motivated by the MUNI hack, as it predated it by 8 months (Rosehub started in March 2016, MUNI hack was announced in November). As noted in the blog post, it was instigated by Justine seeing that open source packages weren't updating their dependencies to protect themselves, then doing some digging and realizing just how widespread the problem was.
However, the MUNI hack certainly did motivate being more public about the project and writing this blog post, since it really helped underscore the severity of this vulnerability in very real, concrete terms.
There's no indication in the questionnaire of who is actually running it, what is being done with the data, whether results will be published and where, etc. Does anyone have more info? Right now, this just looks like a black hole.
Just to be clear on this, Google projects (including side projects of Google employees) do not require copyright assignment in the way that FSF projects to. They require an explicit copyright license, but the author retains the copyright. Full details at https://cla.developers.google.com/about
https://www.fieggen.com/shoelace/secureknot.htm
And like many things on HN, previous discussion: https://news.ycombinator.com/item?id=13399095