@trwnh TIL but for «things I learned» instead of «today I learned»

@jwildeboer why not use the bridge too BS if it's only intended for promotion?

@trwnh oh good point, so if it's done by GET it *must* include the query parameters in the URL. And yeah, now I can see better why POST would be a better choice.

@trwnh hm I'm not convinced. The main issue is that neither POST nor PUT are conceptually appropriate. Among the methods defined by HTTP, GET is the one that's conceptually closest. OTOH, those *are* problems with using a query string. Maybe they could be reduced by other means, such as additional headers or body payload (GET *can* have a payload)

@trwnh doesn't that kind of depend on the type of form? Classically for a something like a search GET would be a more appropriate method than POST or PUT …

@dansup the existing Fedi directory projects are most surely among the ones you'd want to coordinate with:
https://fedi.directory/
https://communitywiki.org/trunk
https://fediverse.info/explore/people

@jonny @thisismissem @smallcircles @peertube

Part of the issue is that the data model and frontend are too tightly coupled. “Microblogging” or “video publishing” or “photo publishing” should be entirely a front-end issue. The data itself *could* in principle be shared between all of them.

The other pain point (“wrong instance”) comes from the Fediverse, and could be solved with OpenWebAuth, which is one of the FEPs proposed as part of the nomadic identity support
https://wedistribute.org/2024/03/activitypub-nomadic-identity/

@jdp23 @djsundog @Eris

no, even if Mastodon was the only AP server software, it still wouldn't be centralized. It is, however, a monoculture, with all the downsides of monocultures, and that is actually one of the most important things that need to be changed. But this requires helping people discover the reality of the Fediverse beyond Mastodon.

@jdp23 @djsundog @Eris other implementations going forward without waiting for Mastodon is good, but it's not enough (case in point, Quote Boosts; nobody cared that other platforms had them). Part of that is a general misconception of what the Fediverse is and how it operates (and one of the reasons I insist on speaking about the Fediverse rather than Mastodon alone), but part of it is that practically the biggest player in town not supporting something *is* a problem. Monocultures are bad.

@trwnh am I reading it correctly that it sounds a bit like how the eDonkey network works? You can connect to any server, and then search for resources (file hashes in that case) and you'll get a more or less uniform view of the network anyway, modulo massive netsplits?

@trwnh OK, but the ID still needs some crytographic element to allow keys to prove controllership of id? Or how would a key be used to prove control?

@trwnh this BTW is also why I'm not to fond the RNS idea (same issue as with DOI and PLC), unless again it's “distributed first” (hence the Kademlia idea). I'm not sure why you're opposed to keys as IDs, but whatever the choice is, it should still provide some key information simply to ensure validity.

@trwnh sorry, I didn't meant it like that, I meant it in a way similar to how DOI works in the sense that the URI could exist without the doi.org domain, and the doi.org domain is essentially a proxy to resolve doi: URIs into HTTP URLs. I think the DID idea could work in a similar way, which is what I think the PLC DID from BS is intended to be, but I'd like it to be “decentralized first”, with the HTTP proxy only useful for the transition.

@trwnh I think that's part of the reason for the choice to go with a different protocol. I guess you could still have some kind of proxy service like there is for DOIs: you have an URI that is doi:prefix/suffix and then you have the HTTP proxy https://doi.org/prefix/suffix that redirects to the known HTTP URL of the document. We could have a similar scheme, but only as long as alternative resolution mechanisms are also provided.

@trwnh if you want resource identifiers to remain valid, you have to decouple their URIs from any specific HTTP URL. You don't necessarily need a centralized system, though. The Portable Objects proposal https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md introduces a new URI that includes a “gateways” parameter that acts as location hint (multiple ones may be present) piggy-backing on DNS. But that's probably too big a change.

@Eris @mekkaokereke (For the changes, I mean something like: a user can ask to be added to a public list in a similar way to how they can ask to follow someone with a locked profile, and similar they could ask to be removed from a list; some of these action could be automatic, but with care: for example, you can remove yourself from a starter list, but not from a public block list)

@Eris @mekkaokereke
so one way this could be implemented is that in addition to my “private” lists that I use to manage my follows, I could have public lists, and anyone browsing my profile could see them and one-click add its members to their follows, or block them (for a block list)? (This doesn't solve the problem of users having to find *me* in the first place, but it would help past that point.)

I guess changes to these lists could come through federation similar to follow requests.

@Eris @mekkaokereke
and that's before even getting into how much of a social problem these are *before* being technical problems. And they are a social problem because of federation (simplifying: “who federates with whom”, which maps also to “who takes recommendation from whom”), but also because of the social interactions involved in the software development itself (there has been recent discussions you probably have come across about how certain thought-out PRs are being disregarded).

2/2

@Eris @mekkaokereke oh yes the ideas are nice, but the problem is, nice ideas have the tendency of not scaling that nicely when decentralization is involved. Consider for example the starter lists idea: where does the server fetch them from to present them to the user? Who manages addition and removal of entries from the list? How do changes to it propagate?
We already have something like that for the “reference blocklist”, and even that essentially relies on a centralized service (Oliphant) 1/2

@Eris @mekkaokereke Mastodon has a lot of room for improvements UX wise (and there's a lot of effort that is going underway even though it's, shall we say, not as considered as it should by those with merge rights), but I'm skeptical about how much BS can be an inspiration for those improvements. How much of the “UX improvements” in BS are a direct consequence of it being a centralized system above anything else? (One example for all: you don't need to choose a server because there's only one.)