Zot VI

Mike Macgirvin
  last edited: Tue, 12 Sep 2017 14:46:24 +1000  
Zot has been in use continually for over five years, with only a handful of minor upgrades. Most of these involved extending the cryptography mechanisms to allow negotiation and deprecate older/insecure algorithms.

During this time. there have been a many changes in the external landscape and there are now some better ways of doing things which didn't exist in a stable form when zot was created. The goal of Zot VI is to bring the protocol in line with some of these changes. As an example we can now provide server-to-server authentication by making use of HTTP Signatures. There are a couple of other places in the protocol where we can reduce the complexity of interactions by using the same technology (increasing efficiency). As a side effect the entire protocol and message flow will be simplified and easier to integrate with external services.

The proposed delivery method for this work is to expose it through a protocol plugin, (just like the other protocol plugins) and ultimately remove communication protocol implementations from core code. As Zot VI will not be directly compatible with zot, this allows a migration path; and servers will be able to support both.


  • Refactor zot-finger
  • Refactor Delivery
  • Refactor magic-auth
  • Refactor Directory Services
  • move to plugin
  • Release timeline
ActivityPub - next steps

Mike Macgirvin
  last edited: Sun, 10 Sep 2017 09:00:39 +1000  

  • provide signing preferences
  • import tags, mentions, attachments - these are currently exported but not the reverse
  • when importing attachments check if a media attachment is already displayed inline and if not, display it
            this is because Mastodon apparently strips such attachments from the actual message body
            for exported activities, such attachments may be displayed twice on Mastodon since we include them in the body
  • support reshare/boost
  • provide cleaner method of message-id cross-checks
  • work towards LD signatures (requires LD sig library), evangelise the superiority of salmon in the meantime
  • https://github.com/digitalbazaar/php-json-ld *may* be useful for LD Sig normalisation/canonicalisation
  • provide verification options for signed data
  • provide C2S API (requires additional OAuth2 integration)
  • do interop testing if anybody from another project shows any interest in interop
  • add voting and event attendance
  • add support for pokes and other non-standard activities
Diaspora Protocol - next steps

Mike Macgirvin
  last edited: Sun, 10 Sep 2017 08:55:42 +1000  
Server to Server Magic Auth

Mike Macgirvin
  last edited: Tue, 05 Sep 2017 15:39:30 +1000  
Server to server magic auth will make use of HTTP Signatures to authenticate servers on behalf of members. Currently zot magic-auth is primarily a client to server technology. This will allow us to access API and DAV services easily without using OAuth or passwords or storing cookies server side.


  • Support HTTP Signatures
  • add signature generation options to curl wrappers (z_fetch_url, z_post_url)
  • ? What to use for a validation header to minimise or avoid replay attack? xchan_guid . timestamp ?
  • Add signature validation to authenticated endpoints (api, dav, cdav)
  • review whether this could be used to simplify the c2s authentication which performs an s2s exchange as part of the process
  • If this turns out to be the case, prepare a zot protocol revision change
Cards

Mike Macgirvin
  last edited: Fri, 25 Aug 2017 11:38:15 +1000  
Description:
    Cards represent a persistent area for collaboration that is separate from the social stream; where planning and discussion tend to get lost without fresh activity after a day or two.  They are somewhat more lightweight than webpages and wikis for quick organisation of information and have the advantage of allowing collaboration and commentary. They are well suited for helping to organise complex tasks where there are frequent updates and feedback.

Todo:


  • publish cards
  • categorise cards
  • (phase 1:) honour read|write pages permissions
  • edit cards
  • add page titles
  • load cards by page title
  • load card by category
  • sync cards to clones
  • export/import cards from channel dumps
  • prevent card federation, these are static website resources
  • allow comment on cards
  • oembed cards
  • fix permalinks so they go somewhere (parent done, children not done)
  • (phase 2:) add specific card permissions
  • create/edit acl
  • make cards searchable
  • export current card to post, import from post
  • provide a mechanism to archive or hide "inactive" cards, but provide an option to display them
  • documentation
  • tests
Mario Vavti
 
I like!
Haakon Meland Eriksen (Parlementum)
 
Is this a bit like cards on a Kanban board? :-)
Mike Macgirvin
  
Is this a bit like cards on a Kanban board?


Sort of.
Issues Management

Mike Macgirvin
  
As currently envisioned, the issues management interface will appear as public (or private) forum with some unique characteristics.


  • The post editor will include some additional fields related to issues management
  • issues can only be posted at the channel page - not through tags; forum tagging will be ignored
  • federated connections using other protocols can observe and comment through message federation, but not create issues
  • connections can be categorised into 'reporters' and 'developers' (and perhaps additional roles) with different permissions
  • reporters will not receive all communications on all issues, but only issues they created or are following
  • developers will receive the entire issue stream
  • provide searching of issues with various characteristics
Large File Uploads

Mike Macgirvin
  last edited: Thu, 24 Aug 2017 16:22:19 +1000  
PHP processes are limited to a certain amount of memory and uploading large files can exceed this limit if the files are uploaded with standard PHP utilities.

Alternatively, there are Javascript libraries which upload files in smaller sized chunks and which are re-assembled on the server. We're currently using the 'blueimp' file upload library to provide this service. This functionality and library interface needs to be extended to other places where files are uploaded.  It is less important on photo upload pages because photos usually fit into memory; although modern digital cameras are always pushing these size limits. Generating thumbnails from photos also consumes a large amount of memory for large photos. Eventually we may need to generate thumbnails in separate processes to keep memory requirements under control.


  • status posts (drag/drop of links and files supported)
  • comments (drag/drop of files not yet supported)
  • WebDAV (files are streamed without using the client library)
  • files uploaded from the cloud page (this one is moderately important and requires drag/drop support)
  • photos uploaded from the photos page (requires drag/drop support)
  • profile photo upload (drag/drop desirable)
  • cover photo upload (drag/drop desirable)
  • files uploaded via zot API.
  • files uploaded via Twitter API (cannot be chunked currently because protocol does not support it)
  • files uploaded via ActivityPub API (cannot be chunked currently because protocol does not support it)
CardDAV, CalDAV core integration

Mike Macgirvin
  last edited: Thu, 24 Aug 2017 11:56:03 +1000  

  • move cdav to core
  • provide translations between ical and hz/red events (partially done)
  • provide detailed task edit beyond simply marking complete
  • integrate the event systems
  • integrate the vcard systems
  • dependency: Server to Server Magic Auth
OAuth2

Mike Macgirvin
  

  • find an OAuth2 library we can work with
  • test it to see if it does what we want
  • integrate it
  • provide automated registration (partially done)
  • phase out oauth1 support
  • add support to /api
  • add support to activitypub