Right. I was / am interested in bridging the gap between talking about our thing and actually having it liveish.
That said if any ordinary user could easily add a “card” such that, easily, it would turn up here it would be good!
BUT how real is that? What I mean is it is not so clear how that would work, yet.
Best, TT
A card to any arbitrary site, or a card to a static tiddler?
The former, not so much, the latter maybe if you could convince Jeremy. I think it would be useful if it could be added to the static images, because likely Google uses the info in its search engines, and many other sites probably use onebox or something similar to present information as well.
Edit: The rich cards seem to be pretty limited in what they can offer. A title, an image, a two line description, a link. I couldn’t get the url link to work correctly. Presumably this could be ironed out if there was interest.
Lack of this in single file tiddler is one of the reasons – from social sharing to SEO – that I can’t really recommend it.
Many links get shared via chat or forums or Twitter – and social previews are very valuable.
This was discussed previously:
And we also removed rich link previews for tw-dot-com
Right – not good for single file wikis. But TW’s parallel static website could have the appropriate OG headers embedded. Including, possibly, a url link to the single file at tiddlywiki.com.
Another possibility –
The blog I linked mentioned that Discourse has “recipes” included for Google, Facebook, etc. That suggests that we might be able to make our own recipes that know how to display from single file TW. Possibly where we define our own url structure without the # symbol but the recipe knows how to bake it back into the output. Like a link to the all operator might look like:
https://tiddlywiki.com/all%20Operator
But the recipe could create the output link as:
The recipes are just for parsing header / open graph / Twitter info. Single file TW / anchor tags don’t carry this info since it’s just a single HTML file.
And yes, totally doable for statically published TWs. Much like generating feeds, open graph support by default for publishing would be an important core feature of such a setup.
This is also a common / emerging pattern for many note apps — where published files are generated from a more dynamic app.
FYI: The above format works out of the box is static tiddlers have being published either as separate files, or automatically by a node implementation.
I have long believed if static tiddlers are published (individual or server generated) that all their links should not point to other static tiddlers but to the permalink within the wiki. This would mean any interaction with a static tiddler, used as a link would load only the target tiddler but any further interaction load the wiki for a full interactive experience.
So if “mother” publishes all tiddlers as static but linked back to mother at publishing time this should work well. The only gap is capturing recent changes to content and adding updating such static tiddlers on the host. It should be easy to create one or more static tiddlers whos modified date is newer than the last static tiddlers export, that the wiki editor can generate from the wiki to the host.
This is in someways related to my recent thread Sending a tiddler or tiddlers via email? which could generate submissions for changes to apply to “Mother”.
Right. The more we simply connect to real TW the better IMO.
Shirley, that is the point? 
TT
Erm. Not so sure.
What can I say? I’d guess whichever method could be done it is always best to easily invoke a live TW. Otherwise why do it? Something like that.
Best, TT
I wanted to follow up on this. The whole “card” thing.
FYI @joshuafontany wrote an experimental plugin that hasn’t had the attention it deserves for TW “Oembeds” https://github.com/joshuafontany/TW5-Oembed. Unfortunately the demo doesn’t seem to be working ATM.
Best, TT
This is just thinking out loud. The recipes are apparently written in a Onebox “Gem” in Ruby (on Rails). Presuming that a headless browser driver exists for Ruby, then it might be able to fetch and parse the actual contents of an address to a single tiddler and set up a more responsive “card”. This would make setting up cards much easier because rather than using a special description field, there could be a default fall back that takes the first 100 characters or so of a tiddler as description.
Just throwing this out there in case there are any bored Ruby programmers hanging around.
This is for embedding other things in TW, not the other way around.
Although the Other thing we embed in TW could be from a tiddlywiki !
I remember @telumire invented an smart solution to use Tiddlywiki lively in a Talk post!
I could not find the thread!
Thanks for keeping this thread alive!
My point in the OP was that there is a “distance” (visually) between Discourse and TW.
I simply think TW would do better if we could integrate a “TW Look” into Discourse.
I did suggest that rather than having links to TW-wikis we embed them. BUT there was concern on it being too much—that it would cause problems on bandwidth & performance here. So I, basically agreeing, abandoned that idea.
However, I still think we could maybe do more to "narrow the gap between talking about TW & using it??" And visual appearance is a big part of that.
I hope this is clear!
TT
Thanks for the mention ! I believe that you are talking about this post : Intended feature or potential security issue ? How to embed an iframe in talk.tiddlywiki
I agree that it would be amazing to have talk.tiddlywiki support tiddlywiki files natively ! Maybe it could allow embedding of html files, in a similar way that codepen does ?
A tiddlywiki theme for discourse could also be good but I’m not sure if the features of this forum are similar enough to tiddlywiki to allow that (sidebar, tags, …?)
It would do that easily. I shown that already. The issue is that there was concern on bandwidth & performance. That it would create problems for some users.
That iframes here on Discourse could cause problems.
That is why I did not push it further. But basic iframing looked well viable to me and easy.
TT
Right. It would be a Second Best. A “Cut Down” version! But maybe still useful?
But I am glad, @telumire, you really get the point of the OP!
Best, TT
A lot of water went under the bridge on this topic, I just reread the whole thing. There are plenty of great ideas and examples and many are 90% towards some useful outcomes.
With tiddlywiki.com not undergoing too many changes every day surely more often than not peoples browsers load it from the browser cache?
Also as I suggested earlier Static tiddlers could
As I understand is depending on how it is implemented the embed process queries the content at the end of the link when you attempt to view that link, so it only does so when you need to see that content. Some forums do it once and save the result of retrieving the card in their database.
The aforementioned data share method, demands a plugin to be installed on the host wiki, at present it is left to us to provision this, wiki.
Performance, whilst for some would be an issue if you decide to load discourse and browse content then you are tacitly deciding to use bandwidth to read content. Even tiddlywiki.com is smaller than many images or audio out there.
I thought you comments interesting.
I still believe that having a Discourse that can incorporate the look and feel of TW would help a lot.
As a second-best I did look at how to get control of the CSS for our Discourse. It is a bit beyond my skill level to actually do it.
What I can see is that it would definitely be possible to …
1 - write posts in a TW; (as normal)
2 - that can be directly posted to Discourse; (via a TW poster macro)
3 - that, in theory, on landing on Discourse, could be laid-out exactly the same as their origin in TW; (needs Discourse end CSS changes).
Just a comment, TT