feel free to leave a comment if you have any ideas for features that might be nice to have

This is awesome! And the timing will be perfect for me. +1 on Minkchat but they both are good. Maybe save eelchat for your interspecies chat startup? Dunno.

At any rate, just seeing you implement the features you mention will be really useful. If this is video based (and totally cool if it isn’t) there’d be insight into the dev workflow. That’s already been coming through on the videos you’ve done, which is great.

One thing I’m into learning is any kind of editing features… for instance, the ability to edit a comment after leaving it. And I’m also into the ability for a series of people to edit a thing (a wiki), but I’m not sure the latter fits into this scenario, which is cool. However, for this or another project I’m keen on wiki type features as I suspect they are a fit for XTDB. Allowing an admin to edit a user’s posts (i.e. remove objectionable content) might be an area where that area does fit here. The fit with XTDB is that the time features would more easily enable a reviewable version history of the comment or wiki-like project element.

Another thing that is roles and auth… admin roles that can edit or remove posts or all of a user’s posts. Perhaps XTDB time features may be useful here as well: for instance, if a user goes off the rails for a stretch an admin could remove posts from a time range. I’m just brainstorming here far beyond the likely scope of a project like this.

But some of those features do seem like ones the real world requires that separate almost useful from actually useful platforms (mainly the moderation features).

I am planning to do videos--I'll do a written version of the whole tutorial first, and then record myself going through it

it's been pointed out that mink chat is similar to "minx chat" which presents some brand safety issues ;) so I think I'll be going with eel chat there were several other decent candidates, like weaselchat or opossumchat

no way http://opossumchat.com was available. no way.

I just took a list of animal names from Wikipedia, appended http://chat.com, and uploaded them in a CSV to name cheap. there were quite a few decent candidates actually. I'll probably try that method for all my future domains

agreed about comment editing stuff, that'd be a good way to demonstrate xtdb document history stuff

Don’t try for http://screaminghairyarmadillochat.com btw. I registered that in 1997. Yes, that’s a real animal.

admin roles also are a good idea, I'll add that to the list

haha OK well clearly that's the best domain, what's your asking price?

Meet you in an airport hanger with your team and my team and we’ll talk it over.

As mentioned I’m keen on feature dev workflow, and in particular in relationship to the db… in particular how one proceeds from, possibly, db interaction in the repl to db interaction from UI. Or, perhaps, you start with the UI, which is something I should consider trying. At any rate, how you go through it step by step would be great. That could be lost in scripted tutorial unless the script follows the sequence you’d use IRL.

good to know--I am planning to have it follow the same actual flow I'd use in regular dev. E.g. sometimes I do start by writing db queries in the repl.clj file and then copy them into ui/request handler. though I also sometimes just start out putting it in the handler, maybe with a pprint if I want to inspect the results

I like 'mink'; maybe because I see one about once a week while birding. They're very cute and camera-shy.

1. you're calling xt/submit-tx but using Biff's transaction format. you probably want biff/submit-tx 2. you should have at least (select-keys req [:biff.xtdb/node :biff/malli-opts]). or just pass in req as is (that's what I usually do) 3. this is a security vulnerability. you need to verify that the current user owns the document with that ID before you delete it

re: #3, what I'll often do is add some middleware to all of the routes that deal with a certain type of document (E.g. with the doc ID in the path params). the middleware takes the ID, loads the document, verifies the current user is the owner, and then adds it to the request map. if the doc doesn't exist or current user isn't the owner, then either pass in the request map as as without assoc-ing anything, or redirect/return a 40X error

and then from the handler, you never look at the path params, only look at the document that the middleware added to the request map

mm yes, this is due to #1 in my other reply. xt/submit-tx is expecting a node, but it's getting (a subset of) the system may instead

Just watched it. Amazing.