100days

This morning I was chatting on Google Hangouts with my brother, currently living in South Korea.  When I left the house, I just picked up the conversation on my phone, but I realized something that hadn't dawned on me before.  The sound it makes is not the sound I set back when I first started using hangouts.  When did that change?  My best guess is that this changed when I Google finally bestowed upon us the ability to set custom sounds for our hangouts conversations.

If Facebook is the "move fast and break things" company, then Google is the "test everything" company.  Google hangouts had so much hype around it.  A place to unify all our communications.  A single place to have merged conversations.  The hype has us believing it would give us a single communication platform.  The reality has been anything but.  Almost immediately people realized the lack of functionality in it.  You couldn't even set custom sounds per person.  I'm sure I'm not the only one who sent feedback almost immediately.  And it took quite some time for that feature to roll out.  WHAT TOOK SO LONG? 

This singular feature isn't just a one off case either.  I feel like every feature users request takes 6 months to a year to roll out.  Google moves with the speed of a tortoise.  Google Hangouts' group chats still don't feel properly integrated.  Try using voice to send a message to a group.  We only recently got the ability to do this with individual hangouts.   I hope Google is very much regretting its deal with Vidyo in the creation of hangouts.  What used to be an open platform of Google chat (XMPP behind it) is now a very much closed system that is slow to add functionality to.

Maybe at some point Google will realize its folly but I suspect we'll have a long time to wait for that too.

I told Ann that I would write up some of my thoughts on why deleting other's posts via any sort of social web api is not needed.  So here it is in my bleary eyed state.

There is a bit of arguement about how groups should work in federated social web.  Realistically there are 3 key concerns, independant sites, public silos, and private company networks.   One of the key points of the indieweb has been control of your own data, so while groups might merge all of these users together, its of particular importance to indieweb that our own posts cannot be deleted by anyone else.   I believe this same policy can work just fine at an API level in group interactions.  Lets start with the indieweb site creating a group, however that happens.  If another indieweb member joins and posts, they are posting their content on their own site, and then a copy is just propogated to the group.  Likewise they are free to pull in the original group conversation back to their own site.  If we abstract this to say that one of those indieweb sites to have multiple people within it, this works just fine.  Go one step further and it is the equivalent of a silo.  Between and indieweb site and a silo, data can move exactly the same way, no indieweb site can delete a post that exists within a silo, they can only delete their own post and tell the silo the post was deleted.  You can swap a company network in for these public silos and again, it will work exactly the same.

With a "group", the question comes in the form of deleting the entire group.  We see in facebook that deleting a group removes all posts within that group.  But in the indieweb, the oposite would be wanted, deleteing a group would do nothing to the original post.  This is actually not a conflict at all when you consider that within a silo, anything can be done.  A silo could choose to delete all posts of its user's when a group gets deleted. A silo cannot delete any indieweb user's content, but the silo can remove all reference to it.  While on the indieweb site, the copies of posts from the silo users might still exist on the indieweb site but all links to the silo copies of these posts would be gone.  The basic thing is that within a silo, there is no limits on how the internal implementation handles this.

Again this all applies equally to any sort of business setting.  If there is a group project between two companies, neither company should be able to delete the posts of the employees of the other company.  Also each company would prefer to keep copies of anything posts from the other company, so as not to lose context to the comments made.  Any attempt to force deletion of content from the other will ultimately be futile as there is always a way to save anything that is viewable by someone.  Inside of a company's system there could be complex systems for deciding who can post, where, how data is archived, approval processes, etc.  It is still all internal implementation, and not an issue for the API.