This page is to document and brainstorm on what to use and improve Tiki in a federated context. Ex.: several Tiki instances need to work together somehow. (vs Workspaces within one Tiki). This includes SisterWiki, InterTiki and the Communication Center.
Xavier's thoughts
- My wish:
- Workspaces were mature enough for that (like course in Moodle, etc). (Power) End user creates a new space, and every thing works (like a jail) by default allowing full delegated perms inside but no extra perms outside.
- However, I fear that Workspaces to be used in production by end users (not by experienced Tiki admins or power users) would need another effort of improvement, and probably, a Tiki Fest to gather and implement the ideas needed to be discussed and implemented in a common direction, etc.
- My implementation if I had little time and/or budget and I needed something like this?:
- federation (separated Tikis) and switch / enable / improve current features for search, login, links, etc., as indicated below. . And maybe reusing Multitiki if all the tikis require same version, and/or tweaks, design, maintenance, etc.
Existing features in Tiki
- Web Services
- Federated Timesheets
- Federated Search, including "Elasticsearch Tribe Node URL"
- Remote Tiki Autologin
- Content Authentication
- External Wikis
- Tracker Synchronization
- Email - Mailing lists - Forum Synchronization
- LDAP Synchronization
- Webmail (IMAP/POP3) Synchronization
- InterTiki
- Communication Center Send and Receive Articles and wiki pages
- CDN
- Raw page display - shared wiki page content served as text/css file type resource so you can do things like federated Sister Sites Customizations with collaborative editing and version history - ideal for quick fixes and there is no more need for copy-pasting manually in Custom CSS textareas and making sure one is keeping the sites in sync...
- Wiki-plugins fetching remote content/wiki pages:
Wishes
Related use case
- Being able to share content between t.o websites, Something like (list of all new stuff in Tiki17):
{include page=tiki17 site=doc.tiki.org filter=h2,h3 truncate_char=70} - Advanced configs of trackers that are on master are replicated on the slaves: Data lives on slaves, and configs are taken from master (need migration scripts of certain changes) for the http://wikisuite.org/White-label-SaaS-platform
- https://suite.tiki.org/Tiki+Suite+F2F
- http://wikisuite.org/SaaS-platform-template
Sharing categories
- Some categories can be shared between sites. Ex.: main site has category list and some sister sites should mirror it.
See also
- IndieWeb Webmentions, etc.
- Microformats
- API
- Distributed data
- XMPP
- Notifications Revamp
- Solid
XMPP-related
- http://xmpp.org/extensions/xep-0004.html
- https://www.goffi.org/b/9555cc02-6a87-4b6b-af85-20f1c0736722/xmpp-based-tickets-merge-requests-with
Groups and permissions
- Group names should be shared between Tikis (like we do for *.tiki.org federation) to permit proper access control.
Related link
- https://en.wikipedia.org/wiki/Federation_(information_technology)
- https://en.wikipedia.org/wiki/Federated_identity
- https://en.wikipedia.org/wiki/Distributed_social_network
- https://en.wikipedia.org/wiki/Webmention
- https://github.com/WardCunningham/Smallest-Federated-Wiki
- https://datproject.org
- GitLab: Implement cross-server (federated) merge requests
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}