2017-12-04
Starting the day off by trying to get unread message preservation working, since this is still sitting in my working directory unfinished. This has been a bit fiddly, but what I have working so far is that the unread flag is not removed until you actually scroll past that post in the feed. Let’s see if this is good enough for now! I also took the opportunity to update the “new” flag in the light theme to match the awesome one in dark.
Great news, after lunch came back and there were a bunch of messages queued up to test with, and works great! Gonna commit this and see how it feels over the next few days.
Looking through all of the places in the various code bases that expect the current users ID. A lot of them depend on ssb-friends
. Wonder if I’ll need to get my hands dirty in that module. Kind of hoped I wouldn’t, but it’s probably the right way.
For the sake of simplicity, I’m going to start prototyping using a seperate index/reducer, then I can start talking to @Dominic about modifying ssb-friends. I also just realised that sameAs should work basically the same as about messages, so I’m going to copy that as a starting point.
Here’s the message that I am currently experimenting with:
{
value: {
…,
"author": "@FbGoHeEcePDG3Evemrc+hm+S77cXKf8BRQgkYinJggg=.ed25519",
"content": {
"type": "contact",
"contact": "@CSkJc/4nUZnkOuRJWhKh/zNaacD6OHy7U2Rhpg4LhNE=.ed25519",
"sameAs": true
}
}
}
That message is me claiming that I am the same person as @matt.exe 2.0. I haven’t yet created the reciprocal message from the other side.
I also have specced out a message for when you want to say someone is someone else:
{
value: {
…,
"content": {
"type": "contact",
"contact": "@EMovhfIrFk4NihAKnRNhrfRaqIhBv1Wj8pTxJNgvCCY=.ed25519",
"sameAs": {
"@H4UWjDPVZRlY7BQw546xcowcCHj1VdFRRCpNT9HQJyc=.ed25519": true
}
}
}
}
My current thinking is that patchwork won’t allow a merge unless at least one of the members of the group has already made a merge claim about the target. So you can agree with something that someone says about themselves, but you can’t say things about random people.
But I have hit an issue with this message that ssb-friends
assumes that all type: “contact”
messages are about following. It isn’t checking to see if the message actually has following
key, it just goes all JavaScript falsy on it. Hopefully we can fix this and not too many old clients will get confused! SIGH!!! Otherwise we’ll have to fall back to copying the current following state into the message. Nasty.
Anyway, at this point, I’ve written a flumeview-reduce that scans for these {type: ‘contact
, sameAs}
messages and collects a list of who says who is who and added some patchcore helpers to contact.async
for merge
and unmerge
. Next step is to take this info and do some smart transforms based on who said what! But that will have to wait until tomorrow.
last minute bug fixes before knocking off for the day
As I mentioned in yesterday’s dev-diary and @jolyon pointed out, the private message count doesn’t seem to be updating when a new message comes through in the latest version of Patchwork for some reason.
It looks like the count is updating for root messages, but not replies. Caused by a recent change that checked to see if a message could be rendered before notifying. It was failing all private replies because it wasn’t unboxing the root message. And it’s fixed!
Started investigating the double up posts. There are a few that I see repeated (e.g. %gwllYPP... and %v4WXlHm...), but it’s not a loop and not in the same order. Something else is going on.
Turns out it’s just messages that have been active for a long time. They have replies stretching across multiple feed pages. I forgot that sbot.patchwork.roots
will be called multiple times with a fresh cache when I did this refactor. And it’s fixed!
I also fixed an issue where the message confirm box was getting truncated since adding the max-height on messages.
—
That’s it for today! Hopefully start getting some merge action going on tomorrow!