%Ro0gvMySDdDM+m2Y3m/IwVACtnc57e+JwPSHV9Dkp2E=.sha256
%TqTiR6207+u4jwozvKv/+Qx/nRK6JhAufFOeR3oqbUU=.sha256
%iRCUPp/IxAK5UEpJVhhV/blNK3GK9WqsSlM0Hufn2ug=.sha256
@cft I would be interested to see a line graph showing: content size versus total size for each message type. I think this would help reveal the cross-over where tinySSB excels. I want to know this because if it only provides benefits for content < 20 characters or bytes, that's ok but not that useful for a social network where most posts are longer.
I think what you're doing could be amazing for LORA.
I wonder if this feed format could be named after a little sea-shell creature
%wrBnXsujnHncFgyI7F3IA92kb4cf6ykCWh+hhzesy28=.sha256
Outside the small-message scenario, tinySSB can not defend its lead against SSB.bipf
@cft Have you measured how vote
s are encoded in tinySSB? They are the smallest type of message common in production. It's small, but I'm not sure if it qualifies as small enough for tinySSB, because just the msg.value.content.vote.link
is an SSB ID. Other than that, msg.value.content.vote.value
and msg.value.content.vote.expression
are tiny.
%go2/bmEA/e3hCWyBRrYs/104WNZZXGqOh6Nj2aYPctE=.sha256
%LmFTy57n0U3gXxcYCegjpRk1idzC5+AwljccW/7cHU4=.sha256
This has everything to do with what I've been trying to achieve with Meshtastic SSB integration! Amazing work @cft.
Not very relevant, but a trick I found to further compress posts, with LoRa in mind, was to use simple string compression (like shorter) on value.content.text
. Doing some test on a random post, I was able to compress 1005 bytes and get 757 bytes. The decompressed string was exactly the same, obviously.