okdistribute yeah
rangermauve Having a DHT to discover feeds related to pogs and then using a materialized view for the actual data seems a bit easier
okdistribute Then it's like AOL
okdistribute 😂 A/S/L?
rangermauve Hell yeah
okdistribute lots of issues with that though in real life.
nettle unless you have superpeers (like internet archive or something) with many resources seeding that long tail
rangermauve nettle: could you elaborate on what you mean by long tail?
nettle rangermauve: the huge amount of relatively unpopular stuff
nettle like the 10ks of npm modules almost nobody uses
nettle lots of resources needing to host them
nettle but little demand
rangermauve Yeah, I think it'd be cool to have stuff be more ephemeral by default. Like, in this world I'd like to see people that are actively advertising they're into pogs and have them remove their entires from the DHT after. It kinda works with hypercore and hyperswarm right now if you create fake hypercores by hashing topics for keys and discovering peers that way. After you close the swarm it'll remove itself from the DHT to
rangermauve prevent false positives
rangermauve And then finding data about others through links and hopefully being able to load data from the peers you got the links through
rangermauve substack: So if I understand correctly, this would be a layer sitting on top of the raw peer discovery / connection code and people would need to do some sort of query to pull data from the overlay?
substack connecting to peers based on topics would happen separately from queries i think
substack but also, implementing some of those papers is a large amount of work
substack the combination of techniques is going to vary a lot based on the different types of apps people make
substack and these algorithms let you calculate a set of peers to connect to who are likely interested in the same topics
substack and with those sets you can also generate meta-topics to use with tools like hyperswarm
substack you can do each without the other
substack kappa-view-query was mentioned earlier, but i think kappa-sparse-query was meant?
substack for some applications, the payload for topic-discovery may be small enough to publish bits of topic metadata to the swarm tech
substack like for example, for peermaps each peer could publish a quadtree bitmap to the swarm with a 1 set for each geographical bucket that the peer has some data for
substack i haven't looked at dat swarm tech in a while but i remember with signal-hub you could publish small metadata payloads
substack looking forward to doing these kinds of experiments soon, after i finish up a few database things and get the ingest working
rangermauve 512 layers of buckets, right?
substack for 64 bytes
substack multiple levels could make sense but i'd need to think about it more
rangermauve This might be relevant to folks here. Found it in the dat comm comm notes. :P https://blog.mozilla.org/blog/2020/03/30/were-fixing-the-internet-join-us/
rangermauve Basically, Mozilla is offering to pay teams of up to 4 people 2500 each to work on some sort of distributed web project
rangermauve I wanna propose a local-network website dsicovery thing based on dat-webext fix-the-internet/spring-mvp-lab#36
decentral1se just shows lack of funding opportunities once again...too little cash to spread around...
decentral1se (cash gone elsewhere no doubt)