I may regret this but since people seem to have a lot of misconceptions about what twederation is and what currently exists I am going to try to explain.
- this doesn't use a client-server architecture. This is important. There are no special nodes so every wiki is treated the same. - everything functions by fetching things from other wikis. There is no way to push anything to another wiki. There is no way to control anything on another wiki. The owner of a wiki has complete control of what happens on their wiki. - this doesn't use a client-server architecture. Given the questions I have been asked this deserves to be said a few hundred more times. - the wiki you wish to fetch things from has to allow you to do it. This means that they have to have the plugin as well in order for the fetching to work. If you want to get something from a wiki that doesn't have the plugin you have to go to the wiki and import by drag and drop like you normally would. - all of this currently works in almost every use case (yes, it can work in dropbox), I will talk about the problems below. - you only talk to one other wiki at a time. There is no server so you have to make connections to each wiki individually. - you can't push anything to another wiki, there is no server and your wiki doesn't have write permissions on any other wiki - you don't need to have your wiki hosted online to fetch from a wiki that is hosted online, so you can pull content from an online wiki onto a wiki stored locally - I have not had any trouble using multiple local wikis stored on my harddrive, I have been able to pull content from one file uri to another file uri At it's base there is a widget that allows one wiki to fetch tiddlers from another wiki based on wikitext filters, it does require some changes to the core. This widget is an extension of how the plugin library works and is set up so that you don't have to build a specific edition to serve plugins from a plugin library, it could be a normal wiki and would work just fine. Everything else is wikitext applications built on top of that. Me and Mat are working on using this to create a loosely connected blogging/social network. It is currently unclear if 'TWederation' refers only to the network of connected wikis or also to the enabling techniques. For the twederation edition that we have been showing off everything works fine if you don't try to fetch things from an http server when you have loaded your wiki from an https server (see below about hosting on dropbox). The 'fetch all comments' buttons on blog posts work inconsistently because it tries to fetch from multiple wikis at the same time and there are collisions when receiving responses so not everything is correctly received. I have a solution to this that I need to implement. But, aside from that problem, the edition works as expected. This doesn't mean that it is easy to use or that there is enough documentation or that my interface is usable or anything else, just that the development is to the point where we are working on the application instead of the enabling technology. Now, there have been a lot of questions about http-vs-https and most of them have missed what the problem is. The problem is that when you load a site on an https server it is normally prevented from loading content from a site on a non-https server. Which means if you open a wiki on an https server and try to fetch content from a wiki on an http server it won't work. That is it. It is a big problem in some cases, but that is the extent of the problem. If you are on an http server you can fetch things from an https server without any trouble. If you are on an https server you can fetch things from another https server without any trouble. The biggest place the http-vs-https problem arises is hosting on dropbox. This isn't as big a problem as I thought at first. http-vs-https on dropbox: If you are hosting your wiki on dropbox than you have access to the file. You can't save your wiki when you open it from the dropbox url anyway, and other people can access your wiki regardless of what type of server they are using. So if you are using dropbox open your wiki locally as a file and other people will use the dropbox url to access it. I am sure I have missed a lot, but that is a brief explanation of what is going on. Richard, For security it is as secure as anything else tiddlywiki does online. Which is to say it isn't really. There are some things we can do to work on this but it isn't really my concern at the moment. As far as scalability goes I never envisioned this as something with thousands of users in one network, or even hundreds really. TWederation isn't meant to be facebook, the point is that you aren't connected to anyone who you don't want to be connected to. While I am excited about ipfs and agree that it or something like it should be (and hopefully will be) how the web functions in the future, the reasons for using ipfs and twederaion are completely different. You may even be able to have your wiki on ipfs and connect to other wikis using what we are making for twederation. If things do go well and people start using the ipfs as an http replacement than the backend will change for how twederation works, but the connections between wikis will function in the same way. I am not convinced that ipfs is going to be any more 'serverless publishing' than the web is now. It is just distributed servers instead of central servers. Talking about distributed systems in terms of client-server architecture causes a lot of problems in nomenclature, but it comes down to 'there is no cloud, only other people's computers'. Ipfs has huge benefits over the current systems, but it doesn't in any way solve what we are working on with twederation, it just gives a potential alternate vehicle for a solution. Josiah, Using twederation you could make multi-user tiddlywikis where each user has their own wiki and pulls any updated content from the other users. This is what the blogging/messages in the twederation edition are. At its base it is just a way to simplify sharing content between wikis. The blogging network we can create using the twederation edition that currently exists is the easiest thing to point to right now as far as what is allows. Another example is I want to do with it is to work more on the interactive fiction engine I made and actually publish content for it. Then people could use twederation to fetch new content from my site into their wikis. In an idea world I would like to create this and then have collaborative world building where a group of people could take the tool and each one could create their own part of the setting and pull in and modify things other people have created. You could have a community calendar that pulls content from different wikis created by each member of a community. I already use it to pull content between different wikis I have on my own computer. That was the original reason I started working on it. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b2958d2e-c65f-405e-99ac-d53e27f9f4ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
