NodeBB-ActivityPub Bridge Test Instance

@natalie 2020???? on bluesky?????????????

@djsundog
1. make browser plugin that does this
2. ????
3. unrestrained extraction and hoarding by the ultrawealthy

@grant so you're saying there's another "this user is literally stealing human bones" situation on our hands

@grant are you tumblr user littlefuckinmonster

@noelle i think they’re more on the basis of “it’s pretty much done but you can request features if anything big is missing but go easy on me”

i am literally typing this out in Toot! right now and idk what if anything is missing that’s important enough to message the dev about

@misty sadly the real disconnect that i think people don’t realize is that the way the system is architected, it’s not “their posts”. the identifier is tied to their service provider’s domain, and the content is tied to their server’s database format. so it’s really “their service’s posts”. by making posts on the service, they give up control. solving this means letting users *actually* own their posts.

this should be made clear upfront so that we aren’t lying to people.

@luna love my kids

i think any "solution" needs to have the following qualities:

- transport-independent.
- stable.
- support aliases.

additional goals:

- easy to adopt. resource resolvers can have gateways or something like a browser extension at worst. you should be able to run a local resolver on your localhost or localdomain.
- recoverable. if someone refers to the resource via a gateway, you should be able to extract *some* info from it and maybe find a different path to the resource (possibly via alias).

in some ways it is a clever idea to have things be identified in a way such that you can easily fetch more information about them. indeed, the web works on this principle. but it’s clever only as long as there is exactly one canonical protocol that everyone uses forever, and our dependence on dns also means that all our identifiers and extant links break when a domain name lapses or changes hands.

@FenTiger also as long as you never reassign a domain name to someone else

@FenTiger it’s clever only as long as there is exactly one canonical protocol that everyone uses forever

idk about y’all but i don’t feel like making a bunch of owl:sameAs, owl:equivalentClass, owl:equivalentProperty statements just to deal with a single letter being inserted

like, damn, we really fucked up pretty badly here. even the semwebby people now have to deal with some concepts being identified as http: and some as https: — mostly by how old the vocabulary is. lol, lmao

as i’ve read it, the w3c tag opposed xri on the grounds that it was unnecessary when http: could do most of what anyone cared to do at the time

i would personally counter that the w3c tag was being extremely short-sighted for what seems to me like mostly political reasons

it’s on one hand“http supremacist” and on the other hand failing to acknowledge the shortcomings of http: as a uri scheme. the very existence of https: as a separate scheme proves this, while failing to address shortcomings.

i wonder if it makes more sense to build RNS as an extension of DNS or if it should be a reimplementation of the same principles but

ah shit i’m reinventing XRI aren’t i

or actually… maybe //host/thing is good enough if you trust the host to not lie about its own resources?

@jens but anyway you dont have to answer that right away. have a pleasant night!

@jens hopefully you at least see why i’m not fully giving up on the RNS idea lol

@jens really my concern here is that losing a key means losing all your resources and breaking all existing links. i don’t think most people want cryptographic guarantees when alternative means of establishing identity will do fine. for all its problems, people generally trust DNS. can we extend that trust to resources? arbitrary name-to-thing lookup where you can register not just IP addresses but also arbitrary resources? like doi: or isbn: but for anything, by any host

@jens if you’d like to pick up at some future point i would be interested in hearing more — the tradeoff with key-based identity as i understand it is that key rotation invalidates old signatures. which is afaik why zot uses a random guid and then signs that guid (iirc). sounds a lot like that tuple you were talking about, but it’s been a while since i read the zot protocol docs.

if you have any other resources you can point to in the meantime (heh), i’d appreciate those