60 Matching Annotations
  1. Mar 2018
    1. by URL All annotations on Ta-Nehisi Coates’ Letter to my Son Atom: https://hypothes.is/stream.atom?uri=http://www.theatlantic.com/politics/archive/2015/07/tanehisi-coates-between-the-world-and-me/397619/ RSS: https://hypothes.is/stream.rss?uri=http://www.theatlantic.com/politics/archive/2015/07/tanehisi-coates-between-the-world-and-me/397619/ by Tag All annotations tagged edu305 Atom: https://hypothes.is/stream.atom?tags=edu305 RSS: https://hypothes.is/stream.rss?tags=edu305 by User Paul Allison’s annotations Atom: https://hypothes.is/stream.atom?user=paulallison RSS: https://hypothes.is/stream.rss?user=paulallison

      Excellent way to add users and tags to the Fediverse (the federation of free networks) -- through Friendica's RSS functionality.

  2. Nov 2017
    1. Shout-out to the notion of "federated wikis" being developed by Ward Cunningham, who developed the first wiki, and Mike Caulfield and Tim Owens.
    1. And that, in fact, is a pretty good description of the IMS standard in development called Caliper, which is why I am so interested in it. In my recent post about walled gardens from the series that Jonathan mentions in his own post, I tried to spell out how Caliper could enable either a better LMS, a better world without an LMS, or both simultaneously.
    2. Stephen Downes built gRSShopper ages ago
    3. Jim Groom's ds106 uses a WordPress-based aggregation system, the current generation of which was built by Alan Levine
    4. Jim Groom's ds106 uses a WordPress-based aggregation system
  3. May 2017
    1. Consumer Federation of America

      This may be a front group. Investigate, find additional sources, and leave research notes in the comments.

    2. Consumer Federation of America

      This may be a front group. Investigate, find additional sources, and leave research notes in the comments.

    3. Consumer Federation of America

      This may be a front group. Investigate, find additional sources, and leave research notes in the comments.

  4. Mar 2017
  5. Dec 2016
    1. An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead. It may not be as beautiful as federation, but at this point it seems that it will have to do. Tweet

      I'm not sure if this comparison is really working: What if I really take the Signal software, because I have reasons to do so. How can I stay upstream compatible, if "upstream" means the master branch of Open Whisper Systems? There soon will be two communities at least for me: the one that I left behind and the one that went with me to the new installation. But how can they communicate with each other? With the installation of the second instance the "Signal" communication has become distributed in a way except for the two instances cannot talk to each other. As moxie0 says above: "When someone recently asked me about federating an unrelated communication platform into the Signal network, I told them that I thought we'd be unlikely to ever federate with clients and servers we don't control."

    2. This reduced user friction has begun to extend the implicit threat that used to come with federated services into centralized services as well. Where as before you could switch hosts, or even decide to run your own server, now users are simply switching entire networks. In many cases that cost is now much lower than the federated switching cost of changing your email address to use a different email provider.

      There it is again: convenience as the main driver for the ecosystem to develop.

      The "cost" mentioned here is the freedom of not having to send my personal social graph to a server that might belong to someone else tomorrow.

      The two things compared do not fit: Switching networks on the basis of a phone number can be compared to switching similar services with the equivalent of an email address. And changing your email provider can be compared to changing your phone company without being able to take your phone number with you.

    3. If anything, protecting meta-data is going to require innovation in new protocols and software. Those changes are only likely to be possible in centralized environments with more control, rather than less. Just as making the changes to consistently deploy end to end encryption in federated protocols like email has proved difficult, we're more likely to see the emergence of enhanced metadata protection in centralized environments with greater control.

      This is just true under the premise of a quickly moving ecosystem and does not need to be necessarily the case in general. A quickly moving ecosystem can be found in the field of social media e.g. But, on the other side, a "moving ecosystem" can also be seen in the global surveillance structures that put a pressure on developers to react quickly. This can also be seen as the competition here.

      What if the protocol is federated, but the development of the app that implements that protocol is centralized?

    4. It creates a climate of uncertainty, never knowing whether things will work or not.

      This is not a technological problem but a social one in the first place. It demands new solutions to reduce uncertainty. The automatic update mechism of Let'sEncrypt! might be a hint to what we should look at.

    5. If XMPP is so extensible, why haven't those extensions quickly brought it up to speed with the modern world?

      Is extensibility the only paradigm for updating protocols alongside the moving ecosystem? Regarding other open source tools like Wordpress the update mechanisms are more convenient (although update happen too often with WP).

    6. A recorded album can be just the same 20 years later, but software has to change.

      Concerning a physical record or tape that's correct. But if you look at the cover versions of songs of the past, it is obvious that there is the desire to reinterpret them, to hear the musical idea of a song in the contemporary cultural context. Thus, "cover protocols" are the reinterpretation and reimplementation of a protocol idea. No one would say, a cover song is an update of the original song. It is a concurrent version, a concurrent implementation of a musical idea and can be understood knowing the original or not. Certainly, music is not software, but if the code is the foundation for software, notes are the foundation for music.

  6. Apr 2016
    1. Reasons Facebook, Twitter, and Instagram have dominated the Web over blogs and independent sites:

      • People prefer a single interface that makes it easy to flip or scroll through the new stuff. They don't like visiting a dozen different sites with different interfaces.
      • Most people don't want to deal with site structure or complex editors, let alone markup languages or servers.
      • Facebook quickly became a friends-and-family network, which pulled in more of the same.
      • Following and unfollowing should only require a single click.
      • Retweets and mentions introduce new people to follow, even if you aren't looking for them.
      • Reposting should be easy, include obvious attribution, and comments should be attached.
      • RSS readers had the potential to offer these things, but standard ways of using it were not widely adopted. Then Google Reader pushed out other readers, but was nevertheless shut down.

      Let go of the idea of people reading your stuff on your site, and develop or support interfaces that put your readers in control of how they view the web instead of giving the control to the people with the servers.

  7. Dec 2015
  8. Nov 2015
  9. Jun 2015