docker build on one of my production nodes (_the ingress node_) π±
- It will be possibly to page through much larger quantities of twts per feed, this is potentially unlimited (_depends on disk space_)
- Automated Feeds (_bots_) like @tiktok will now behave/display very differently. You will see all it's historical Twts, whereas before you'd only see the one because the
MemoryCache's behavior was to "replace" Twts.I'm _hoping_ everything else remains the same and true to what we've collectively built and to spec. Replies work, Forks work, various views, filters and so on still work. I'm developing this new cache in a way that uses a "delegate" pattern and a double read / double write with metrics so I can over time see that none of the "old cache" is used anymore.
SqliteCache is almost ready for prime time π€
yarnd π€£ I _might_ revive yarns (_the crawler / search engine_) one day π€
$ bat 'https://twtxt.net/twt/lnrgahq' | jq '.text'
"(#4xaabhq) thanks @prologic!
@bender the idea of the RFC was to reach an agreement on a difficult problem, receiving proposals, and the voting is a simple count to gauge the sentiment of \"is this a problem worth to be fixed?, are we committed to implement a change in our clients?\"
But that's a fair point. What do the community expect? What do y'all expect?"
π€
followers follows mutes tables and expect the client to actually filter Twts appropriately before Display? This would simplify the SqliteCache considerably and also mean it would be agnostic of single-user or multi-user as that's delegated to another layer. Hmmm π§ 
# refresh = metadata field for those that yell loudly enough can add to their feeds. Otherwise yarnd uses WebSub between pods and is fairly dumb. I could never find an "intelligent" way to back-off without hurting freshness.
Thanks @xuu
:{:|:&};:
tt2 ignore such items in feeds and you're good π
yarnd already filters/ignores them (_for now_)
yarnd π€£
>
> In 2012, Prabhakar joined Google after severe funding cuts in Yahoo!'s research division.[19] In 2018, he was > put in charge of Ads and Commerce at Google and in 2020 his scope was expanded to include Search, Geo, and Assistant.[20] [21]
>
> In 2024, he transitioned to the role of Chief Technologist at Google.[2]
> Video unavailable
π₯²
@eapl.me@eapl.me@eapl.me for me, which then gets eaten as two mentions, probably matching twice against my following list?
yarnd pods that form a "distributed network".
yarnd already forms a sort-of "distributed network" amongst its peers and whilsts uses Twtxt (_of course_) is both decentralised and distributed. Nothing wrong with that. -- I tried to build a search engine and crawler, but getting that resource efficient and useful is hardβ’.So if we can have a small network of participating members of the community forming a "distributed network" of the Twtxtβ’ space, we can solve this problem quite easily. We could even put some GeoDNS routing in place and a single A record/domain to make things even easier. Let's call it s "Registry Service" if you will :)
finger π€£ and "plan" files π
> development that requires a database
Obviously I wasn't in the discussion so I feel like I'm missing some context here π€
> The beauty of twtxt is, you put one file on your server, done. One.
I'm not talking (_nor ever was here_) about that. We should be allowed to and encourage dot evolve its usage and our own.
It would be far better as a community to focus on the utility of our tools, services, protocols, formats and specifications as well as our own clients and usages thereof rather than this "idealised" design from (c) 2016.
If you strongly disagree with this, then I think I'll just honestly step away from all of this as the back 'n forth on this whole "beaty" and "simplify" argument is honestly wearing me down π’
> How do I know what a hash refers to?
I believe the reason for this stems from a curiosity of the user of whether they _might_ find that thread interesting or whether there are new interested feeds to follow?
Although my idea increases complexity slightly (_introducing a new concept_) I don't think it's particular hard to understand, reason about or implement (_complicated_). One could even even make the implementation quite simple in fact.
Either way, the idea of a service (_cantralised_) or participating clients/registries (_distributed_) providing reverse hash lookups doesn't sound too bad really.
What do you propose to solve the above problem? π€
> What is this hash?
> What does it refer to?
Idea: Why can't we all agree to implement a simple URI scheme where we host our Twtxt feeds?
That is, if you host your feed at
https://example.com/twtxt.txt -- Why can't or could you not also host various JSON files (_let's agree on the spec of course_) at https://example.com/twt/<hash> ? π€That way we solve this problem in a truly decentralised way, rather than every relying on
yarnd pods alone.
-- Yesterday afternoon the local creek near us had already gone several inches over the footbridge too! π±π± 
