-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable tanglePrune #8
Conversation
A few issues for the future popped up Also found a bug (fixed it here) that also exists in ssb-tribes ssbc/ssb-tribes#70 |
|
||
test('tangle prune', async (t) => { | ||
const ssb = Testbot() | ||
const ssbId = ssb.id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🌶️
(emoji for potential spicy problem)
With different feedFormats, the "id" of an feedId is of different lengths, this means that if recps
is a GroupId + 15 feedIds.... they could be "sigil" style or "ssb-uri" style.
We need to clarify in a spec "when you are DM'ing a person to add them to a group, which feedId do you use?"
Is it their rootFeedId (which is bendy butt ssb-uri?)
cc @arj03
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EASY solution @Powersource - assume all ssb-uri of the longest length, which would currently be:
https://github.com/ssbc/ssb-uri2/blob/main/test/fixtures.js#L17-L26
this long:
ssb:feed/gabbygrove-v1/FY5OG311W4j_KPh8H9B2MZt4WSziy_p-ABkKERJdujQ=
or wait... what is this
ssb:feed/buttwoo-v1/FY5OG311W4j_KPh8H9B2MZt4WSziy_p-ABkKERJdujQ=/Z0rMVMDEO1Aj0uPl0_J2NlhFB2bbFLIHlty_YuqArFq=
Yeah we need a spec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can they be URI style though? Have we allowed that anywhere actually?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ssb:feed/buttwoo-v1...
do we also know that this is the longest possible string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also worth considering this
ssb-tribes2/lib/tangle-prune.js
Lines 8 to 15 in dc4e7bf
// these variables are calculated in | |
// test/tangle-prune.test.js | |
// if these variables are out of date and | |
// * smaller than supposed to: we'll prune a bit much, tangles will converge a bit slower | |
// * bigger than supposed to: we'll prune less than we can. users might run into 'the message you want to publish is too big' more often | |
// but either way no catastrophe | |
const MAX_SIZE_16_recps = 5546 | |
const MAX_SIZE_1_recps = 6041 |
|
||
let lower = 4000 | ||
let mid | ||
let upper = 8000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥 set upper to 17000
https://github.com/ssbc/ssb-buttwoo-spec#validation
the content length in bytes. This number must not exceed 16384.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we change this to 17000 now then later when I do #10 this test won't start failing. I sort of want it to fail so I know that I actually managed to swap the format. But maybe there are more solid ways to test which format we're using?
const content = (prevCount, numRecps) => ({ | ||
type: 'post', | ||
text: 'hello!', | ||
recps: new Array(numRecps).fill(ssbId), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically, this need to follow the format
recps: [GroupId, FeedId, ... ] // you need to consider the length of a FeedId here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to confirm the the recps we're gonna support. See 🌶️
//console.time('prune') | ||
const result16 = tanglePrune(content(4000, 16)) | ||
//console.timeEnd('prune') | ||
t.true( | ||
encodedLength(result16) <= max16recps, | ||
`pruned ${4000 - result16.tangles.group.previous.length}` | ||
) | ||
|
||
const result1 = tanglePrune(content(4000, 1)) | ||
t.true( | ||
encodedLength(result1) <= max1recp, | ||
`pruned ${4000 - result1.tangles.group.previous.length}` | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a feeling it's a good idea to check we're in the right ballpark and not just under a certain number. So changing this to something like this instead
const e = encodedLength(result16)
t.true(e > max16recps - 200 && e <= max16recps)
In a video call with Jacob, I suggested a different way of checking whether the content is too large, without hardcoding the choice of feedFormat: we can just catch the error emitted from ssb.db.create, and if that error matches "too large" (either matching the err.message string, or we can come up with error codes like err.code === 'ETOOLARGE'), then prune and retry ssb.db.create. |
yeah that could work, could make it less resource intensive by just cutting the number of The tricky case to test is whether it copes when you call |
i feel stuck, which of the options should i go with? |
@Powersource I think it's the same approach (i.e. catch the error emitted from ssb.db.create then prune then retry), but Mix was suggesting that we should beware of the performance. Ahau uses ssb-db1, and ssb-db2 is faster, but the error-catch-prune-retry approach might be somewhat slow, so let's just write a test that adds 5000 messages with this API, and measure how long that takes, e.g. with |
agree. Try Staltz's suggestion, and we see how bad it is! |
fixed with #19 instead |
Based on #5