College is running an ad campaign, one of your co-workers saw it (consciously or unconsciously) earlier in the day, and that is what lead to the college coming up in conversation?
Are the founders hoping for additional kitten games? It seems that the game art is protected by copyright and trademark. And the breeding game itself is possibly covered by a patent. But what about representing this kitten data as cats elsewhere? I can't tell from the Terms of Use if this is encouraged or discouraged.
"A. You acknowledge and agree that we (or, as applicable, our licensors) own all legal right, title and interest in and to all elements of the App, and all intellectual property rights therein. The visual interfaces, graphics, design, systems, methods, information, computer code, software, services, “look and feel”, organization, compilation of the content, code, data, and all other elements of the App (collectively, the “Axiom Materials”) are owned by Axiom Zen, and are protected by copyright, trade dress, patent, and trademark laws, international conventions, other relevant intellectual property and proprietary rights, and applicable laws."
This is a cool scheme to address the problem of URL-impermanance due to the fact that DNS name ownership/control can change over time. It allows you to specify a URL plus a date.
I wrote a short blog post about the problem a few years back, and the Tag URI scheme ended up being one of the best solutions I came across, which is how I know about it. Some links in that post and comments may be of interest to people: https://masonlee.org/2009/08/21/is-the-web-sticky-enough/
Interesting to think about for sure. Facebook's algorithmic solution seems to be that to the extent that any post is a true draw to Facebook, that post will get more likes and thereby be more likely to percolate up into other users' main feeds. Boosting that post will therefore cost less. This provides sort of a sliding scale without pricing tiers.
Yeah, getting the main feed right is a general issue for Facebook.
If someone really wants to know about a few bands in particular, liking some of their posts will cause more of their stuff to percolate up into the main feed. But they have to keep liking.
To see all posts from bands one can make an "Interest List" containing the bands. Posts from members of that list will show chronologically. But I don't think showing all posts is the solution to getting users the info they want.
What happens if a band page creates a Facebook event? Does the event get recommended to likers nearby the event? That could be an approach.
Author is probably correct in that Facebook needs clear guidance here.
"Then you suddenly changed the way Posts are seen by people who have already followed a musician’s page to the net effect that an average post is seen by a tiny fraction of the people who have liked the musician."
As Facebook user and band-liker, I don't want to see every post from a band-- just the posts that are relevant to me.
I'd expect that Facebook's current post "boosting" mechanism should work excellently for self-managed, touring musicians: Make a post about a local show, then pay just a couple dollars to "boost" that post specifically to users who like your page and live in the area of the show. The UI for boosting and targeting posts is super easy already, and we should expect it will just keep getting better.
Is the author asking for automation of the posting/boosting for multiple tour dates?
I would think it's that SMS and telephone features don't map well to multiple users. Would you share them across accounts or block them for all but one user? It's just weird.
Textie Messaging on iOS and Android is all SSL and doesn't scrape your address book. It can also text with people that don't have Textie by sending free SMS or email.
Unfortunately, there's no way to differentiate between an app using the address book locally and an app uploading the address book to its servers. Both actions require the same permission.
It would be really cool if Apple provided some new "sandboxed" UI elements for displaying contact names and photos locally without allowing general programmatic access to that data, and thereby not requiring a permission. E.g. "Show sandboxed contact image for local contact with email address [email protected], or default image if none."
It would be sweet for trusted computing if developers were able to submit source directly to an app store for the app store to compile, sign, and make available along with the binaries.
While the security of the hash itself can be a concern, the technique is always valuable:
1. In particular, the domain of email addresses is less vulnerable to rainbow tables than the domain of phone numbers.
2. Using salts and a slow hash function improves security by requiring custom rainbow tables that take longer to build.
3. In a B2C situation, an easy appeal to justice can be made that a business should not be making a concerted effort to break its own customer privacy protection. This would not look good in court.
4. If additional consumer protection laws are needed, one-way hashing for the purpose of privacy could be considered a form of pro-consumer DRM. In that realm we have precedents for anti-circumvention laws and contracts.
https://medium.com/@paulbars/magic-internet-money-how-a-redd...