#social 2018-08-13
2018-08-13 UTC
# 
puckipedia yes
# puckipedia what else would you use
# puckipedia the ID is guaranteed to be dereferencable
# puckipedia how else would you get e.g. the actor
# puckipedia actor is for activities, attributedTo is for the rest of the objects
# puckipedia so if you create an object, the Create has an actor, and the e.g. Note has an attributedTo
# puckipedia because you can e.g. Announce a post which is attributed to someone else
# puckipedia and attribiutedTo, apparently, is more generic
# puckipedia (an object can be attributed to another object)
# puckipedia aaronpk: no
# puckipedia
{type: Announce, actor: puckipedia.com, object: {type: Note, attributedTo: someoneElse, content: henlo}}# puckipedia for Creates, you can consider it to be equal to the object it's holding, I guess
# puckipedia and for others, it's always
{actor} {type}d {object}# puckipedia yes
# puckipedia aaronpk: if you give it an Announce activity, you probably want to parse it as "
{user} boosted {post}"# puckipedia it can also be inverse.
{type: Create, object: hxxps://puckipedia.com/asdf} is a valid object# puckipedia which is what some tools will output and what litepub might just require
# puckipedia from what I understand
# puckipedia eh, what I do is usually create a class ActivityPubHandler
{ Map<String, Object> Cache; Object get(String url); }# puckipedia and get() GETs the url, then recursively flattens the object, so every object is replaced with an ID string
# puckipedia which makes processing it 10x easier
# puckipedia I mean, like, per-thing cache
# puckipedia the cache doesn't have to be long lived, it's all in memory per request for me
# puckipedia also allows you to easily trust same-origin inlined objects only
timbl, puckipedia, kaniini, xmpp-social, vasilakisfil, cwebber2, distopico and cdchapman joined the channel; minty-hime left the channel
# kaniini so, right now, mastodon has a feature where
# kaniini you can have foo@domain but the actual AP server is foo@mastodon.domain
# kaniini the way this works is by using webfinger
# kaniini it'd be nice to have a preferredHostname field in addition to preferredUsername
# 
aaronpk that's how https://fed.brid.gy is able to be your AP server
# kaniini it's not, because mastodon hacks it with webfinger
# kaniini but pleroma is pure AP, we don't care about webfinger except to find AP links
# kaniini yes :)
# kaniini when you @foo@domain in pleroma, it generates that using preferredUsername + the host of the URI the AP actor is found at
# kaniini we presently do
# kaniini but people want to be
# kaniini @foo@foo.com
# kaniini not @foo@mastodon.foo.com
# kaniini hince, preferredHostname
# kaniini they don't want to do that :)
# kaniini an example would be
# kaniini it responds with
# kaniini acct:Sir_Boops@sergal.org
# kaniini and mastodon sets up the mapping as @Sir_Boops@sergal.org
# kaniini pleroma does not care about the subject field
# sknebel .oO
# puckipedia hmm.
# kaniini and sets up the mapping as
# kaniini @Sir_Boops@mastodon.sergal.org
# puckipedia so, hm
# sknebel Without further authentication that the second domain is fine with that?
# puckipedia I don't know if preferredHostname would be the "best way" to implement this. I'm thinking about this now
# kaniini sknebel it is only allowed for cases where the AP server is a subdomain
# kaniini and the other domain responds with webfinger
# sknebel That's still... Iffy
# puckipedia sknebel: I'd consider a subdomain a sub-origin, the person controlling the main domain can always control subdomains
# kaniini e.g. https://sergal.org/.well-known/host-meta 302s to https://mastodon.sergal.org/.well-known/host-meta
# kaniini i think depending on webfinger for this is a horrible idea
# puckipedia yeah
# puckipedia I mean. this might hook into my idea a bit
# kaniini i don't want to make webfinger a critical component of pleroma
# sknebel puckipedia: but in practice they can be run by totally different entities
# kaniini in pleroma if you want to, you can disable webfinger
# kaniini (this is not really documented, but it is possible)
# puckipedia sknebel: the entity owning example.com can control what is on whatever.example.com
# puckipedia no matter what
# puckipedia assuming anything else is bad form imo
# kaniini anyway, it would be nice to have an AP way of signalling this
# puckipedia kaniini: so. I've been thinking about this relative to nomadic-ish identities, I guess? did:[public key of user]:[some other id] e.g. did:AAAA[..]AAA:/status/asdf
# puckipedia you'd definitely need some kind of 'preferred host' in this case too
# kaniini aaronpk it proves it by forwarding webfinger
# kaniini aaronpk i think it would be ok to prove it by forwarding the actor URL too
# puckipedia mmh, wondering
# kaniini but the problem is
# kaniini then you have servers who know the actor as
# kaniini http://sergal.org/users/Sir_Boops
# puckipedia oh yeahmm.
# kaniini and also
# kaniini so i think internally it is best to know the actor as http://mastodon.sergal.org/users/Sir_Boops
# puckipedia yes
# kaniini and use some sort of display hint
# kaniini fed.brid.gy works fine with pleroma
# kaniini to my knowledge
# sknebel Through webfinger
# puckipedia I guess aaronpk means that you could do @example.com@example.com and it'd point to fed.brid.gy/example.com?
# puckipedia right
# kaniini sknebel pleroma does not use webfinger to validate identities at all
# puckipedia aaronpk: hm. adding a scope to public keys in activitypub
# kaniini quite literally, it just queries webfinger to see if there is an AP url, and that is it
# puckipedia so you can say "this host and this host can host objects that are signed with this key"
# sknebel There really shouldn't be any difference between a solution for Subdomains and for entirely different domains
# puckipedia (where 'signed' is "returns http signature in the response header" imo?)
# puckipedia aaronpk: right, that's what my suggestion is now, the scoped keys thing
# dansup a wild outbox appears :D
# puckipedia dansup: don't forget mentions
# puckipedia nope
# dansup puckipedia: yup, still have some work to do for the outbox :)
# puckipedia also lol am I really the only one who changes `to: ["[..]Public"]` to `to: "[..]Public"`
# puckipedia well, I'm not even doing it on purpose
# puckipedia RecursionError: maximum recursion depth exceeded in comparison
# puckipedia nice
# dansup pixelfed uses outbox to import posts of new remote users
# dansup the most recent 20 posts
# puckipedia well wh-oh
# puckipedia WHAT
# puckipedia dansup: hey hey
# puckipedia don't give activites and the objects the same id
# puckipedia nothing likes that
# puckipedia and will break for boosts
# puckipedia currently it doesn't and my frontend really doesn't like it
# puckipedia also haha there's like, an Image type for objects
# puckipedia and noone uses it
# dansup heh
# puckipedia kinda hoped pixelfed'd use it
# kaniini puckipedia it has limitations
# kaniini if you use an Image it will not show right in other software which will convert it to a Note somehow internally
# puckipedia ow, yeah, the mastodon conversion is bad
# kaniini pleroma has good support for non-note objects
# puckipedia yeah, same in Kroeg
# kaniini did you see how it renders plume articles? ;)
# puckipedia I haven't
# puckipedia kaniini: so hey. random q:
# puckipedia what're your opinions on e.g. `actor: ["a", "b"]`
# kaniini litepub disallows it
# puckipedia or `to: "https://www.w3.org/ns/activitystreams#Public"`
# puckipedia also, what about an array for attributedTo
# puckipedia the to thing is a thing I actually have
# puckipedia the attributedTo array is ... peertube iirc
# kaniini the to thing is fine
# puckipedia right
# puckipedia I suggest Pleroma fixes that then :P
# puckipedia (pretty sure that's the reason it won't federate)
# kaniini puckipedia ...?
# dansup puckipedia: I forgot to update the outbox transformer, will fix! https://github.com/pixelfed/pixelfed/blob/dev/app/Status.php#L55
# kaniini puckipedia what wont federate with what
# puckipedia kroeg to pleroma
# kaniini puckipedia which issue...?
# puckipedia the to being not-an-array?
# kaniini pleroma doesn't care
# puckipedia mm
# puckipedia I was pretty sure that was the limiting thing for kroeg->pleroma federation
# kaniini do you have an activity
# kaniini that i can fetch
# kaniini i will check it against our linter
# puckipedia https://puckipedia.com/ae4ee4e8be/activity (https://puckipedia.com/ae4ee4e8be/activity.json for AS2)
# kaniini ok give me a moment
# puckipedia the JSON is basically what you get posted, bar some slight differences (due to authentication)
# dansup kaniini, puckipedia: Can you fetch my actor object properly? https://pixelfed.social/dansup
# puckipedia ehm eek
# puckipedia answer: no
# puckipedia because I don't follow redirections
# puckipedia and the Id of the user is https://pixelfed.social/users/dansup not https://pixelfed.social/dansup
# kaniini dansup no
# kaniini https://pixelfed.social/users/dansup returns 404 when Accept: application/activity+json
# kaniini very bad, not litepub compliant
# kaniini tsk tsk
# puckipedia kaniini: it's actually a 302 but
# kaniini puckipedia that is IR leak
# kaniini oh
# kaniini pixelfed
# kaniini lol
# puckipedia yeah
# kaniini manuallyApprovesFollowers = 0
# kaniini :D :D :D :D
# dansup ok, thanks the the feedback
# dansup for the*
# puckipedia imagine if that'd be like, 5
# puckipedia jkust what would happen
# dansup puckipedia: yeah its not casting to bool, https://github.com/pixelfed/pixelfed/blob/dev/app/Transformer/ActivityPub/ProfileTransformer.php#L26
# kaniini featured should be
# kaniini https://pixelfed.org/ns/featured
# kaniini or similar
# puckipedia or, well
# kaniini that's your own extension to the vocab ;p
# puckipedia kaniini: so.
# puckipedia technically, it'd be "http://joinmastodon.org/ns#featured":
{"@id": "[..]"}# kaniini no i don't want to hear your json-ld sales pitch
# kaniini ;P
# puckipedia which is a pain
# puckipedia ... but the inverse is a pain for me
# puckipedia and other json-ld-using implementations
# kaniini yeah?
# kaniini i was informed that URI keys with values was fine by cwebber2
# puckipedia yes, however
# puckipedia "https://example.com/ns#whatever": "asdf" gets parsed as a string "asdf"
# puckipedia "https://example.com/ns#whatever":
{"@id": "asdf"} gets parsed as an *id* "asdf"# puckipedia because objects
# kaniini yeah? litepub doesn't care about that :P
# puckipedia I guess you could put
{"http://joinmastodon.org/ns#featured": {"@type": "@id"}} in the context# kaniini i will make a note of it in the JSON-LD compatibility guidelines
# kaniini but as JSON-LD compatibility is optional, you may wind up just ignoring some extensions :P
# puckipedia kaniini: also like, how deep will pixelfed embed objects
# kaniini that's a question for dansup
# kaniini idk anything about pixelfed :p
# puckipedia s/pixelfed/litepub/
# dansup puckipedia: what do you mean?
# puckipedia freaking names
# puckipedia now it's a kaniini question again
# puckipedia :P
# kaniini puckipedia not deep at all. litepub requires the use of pointers URIs to do capability enforcement
# puckipedia but like, is it expressly defined for every property
# puckipedia like, can/may/may not be embedded
# kaniini yes, embedded objects are not allowed
# puckipedia mm
# puckipedia i guess
# kaniini a litepub implementation will dereference the ID from object.id if an embedded object is supplied
# puckipedia that's different from "not allowed"
# puckipedia that's a "should not" :P
# puckipedia anyways, aaronpk: ^ it could happen anyways
# kaniini puckipedia it is not allowed for an implementation to *send* over the wire
# kaniini if it *receives*, then it handles it by doing the object.id thing
# puckipedia rubs hands
# kaniini and if the object is not fetchable at it's ID
# kaniini then the message is discarded
# puckipedia
{"attachment": [{"id": "[..]"}]}# puckipedia what now
# puckipedia :P
# kaniini it's the root object that is like that
# kaniini attachments are supposed to be fully defined
# kaniini anyway, kroeg can interop with litepub implementations or it can do crazy shit
# kaniini it doesn't matter to me
# puckipedia anyways how's the linting of the activity going?
# puckipedia aaronpk: I'm totally building a gopher-hosted acitivtypub server now
# puckipedia anyways it takes like two seconds to add an @context saying "hey this extension is an id"
# puckipedia aaronpk: yup. add
{"https://example.com/extension": {"@type": "@id"}} to the context# puckipedia shrug, those at least get parsed the same way
# kaniini there are things *you* want to mark with types, there are things where we have the type information separate
# kaniini anyway
# kaniini this isn't productive
# kaniini cwebber2 can you remove preferredUsername if you do not wish to have preferredHostname then
# kaniini since it only exists for @foo@bar addressing
# kaniini thx
# puckipedia meh, I'm ok with that
# puckipedia but then, what would you use as @
# puckipedia like, @whomever as mention
# puckipedia @https://example.com/users/foo? :P
# kaniini yeah? well
# kaniini that is all pleroma uses preferredUsername/preferredHostname for
# puckipedia i mean yeh pet names but
# kaniini but
# kaniini yeah
# kaniini expecting socialcg to care about actual users
# kaniini what was i thinking
# kaniini adds fixing this mess to the growing litepub todo
# puckipedia kaniini: the thing is, I don't think preferredHostname is the best way to do it, but I do think there has to be a way
# kaniini here's what i know
# kaniini your average mastodon user
# kaniini is not interested in typing @https://foo.com/~alice
# kaniini and
# kaniini your less than average mastodon user wants to be addressed as @user@domain, not @user@mastodon.domain
# kaniini yes
# kaniini pleroma does that
# kaniini again
# kaniini people care about vanity
# kaniini i giveu p
# puckipedia cwebber2: that still doesn't fix the gap in finding users
# puckipedia and showing e.g. shorter handles in the UI
# kaniini people care about email-style addressing
# kaniini i am sorry
# kaniini that is the reality
# kaniini i get that they shouldn't, but they do
# kaniini also, pleroma and mastodon already have a dropdown
# puckipedia cwebber2: no not those
# kaniini can you let me finish
# puckipedia kaniini: there's use in having @whatever@mastodon.social vs https://mastodon.social/users/whatever
# puckipedia ehm
# puckipedia s/kaniini/cwebber/
# kaniini this isn't about the UX experience of mapping users to URLs
# kaniini there is already a dropdown
# kaniini and you select the user
# kaniini and it completes it and so on
# kaniini this is about the @whatever@mastodon.domain vs @whatever@domain
# kaniini some people want to be @whatever@domain
# kaniini and refuse to use pleroma since it has no answer to this
# kaniini mastodon does this using webfinger
# kaniini if you want to push pleroma, and by effect, litepub into mandatorily requiring webfinger, not acknowledging this concern leads to that path
# kaniini i do not want to do it the way mastodon does it
# kaniini i want to do it in a pure AP way
# kaniini to get the @whatever@domain identifier, pleroma uses @whatever@<host part of URI of actor>
# kaniini where preferredUsername = whatever
# puckipedia now you're considering "/@[username]" special
# kaniini look
# kaniini this is all great and good but it doesn't solve the industrial problem
# kaniini the problem is that mastodon allows you to use a separate *displayed* domain
# kaniini for the shorthand
# kaniini all the URLs etc they all remain the same
# kaniini they presently do this by returning an alternate subject in their webfinger response
# puckipedia looks at Profile type in AS2
# kaniini what i am asking
# kaniini and would appreciate help with
# kaniini is finding a way to do away with that webfinger hack
# kaniini while achieving the same goal
# kaniini yes
# kaniini if pleroma does not see a preferredUsername it just displays the URI
# puckipedia kaniini: would this require dynamic code on the preferred hostname?
# kaniini if mastodon does not, well, i do not know what it does
# kaniini you would, but the problem is
# puckipedia kaniini: it requires preferred username
# kaniini some people want the actor
# kaniini to be on subdomain
# kaniini so having a 302 to the actor would be fine for example
# kaniini look
# kaniini if it were up to me
# puckipedia I don't think having a 302 would be acceptable for a lot of people
# kaniini i wouldn't have even allowed this
# kaniini to begin with
# puckipedia like, imagine e.g. activitypub.smallcompany.com
# kaniini i am just trying to do this as close to "the right way" as possible
# puckipedia annoyingly this would require active validation
# dansup puckipedia: whats wrong with 302?
# puckipedia dansup: what if the reason you don't want an AP server on the root is because it would conflict with site contents that are already there
# dansup ah, I see
# kaniini i guarantee you that if you don't give the implementors what they need they will move to a different protocol
# kaniini or, back to OStatus
# puckipedia I once implemented OStatus according to spec and it didn't federate with anything lol
# kaniini the diaspora protocol is also attractive
# kaniini zot is also attractive
# puckipedia turns out "optional" is not that optional when all the implementations implement and expect it
# kaniini you can summarize it as a conflict, but these are frequently what users expect
# kaniini and as implementors we have to provide what users want
# puckipedia are you willing to break existing behavior? :P
# puckipedia did GNU social support the disconnect between domain and displayed host?
# kaniini anyway
# kaniini every interaction i have in here makes me believe that adopting activitypub was a grave mistake
# kaniini i am asking for the ability to *not* depend on webfinger, and being told email addressing is stupid
# puckipedia kaniini: btw, do you have any idea for a webfinger replacement for identity /discovery/ yet?
# puckipedia honestly the simplest webfinger replacment would be .well-known/activitypub?username=person -> returns the AS2 object for person@[whatever domain]
# puckipedia assuming .well-known usage
# kaniini puckipedia i don't want the federation protocol to depend on webfinger
# kaniini i mean, there's a lot about AP i really like
# puckipedia aaronpk: I mean, everyone's usage of federated social networking so far breaks fyn
# kaniini it is just very frustrating to come here, and ask a question as somebody who has implemented this thing
# kaniini and get told that email addressing is stupid
# puckipedia cwebber2: the webfinger at foo.example still points to social.foo.example/~person
# puckipedia I guess?
# puckipedia I mean, some username -> ID mapping still has to happen
# puckipedia no matter webfinger or osmething else
# kaniini cwebber2 i was going to have it only allow if has the same root domain
# puckipedia I just remembered there's a public prefix list
# puckipedia but yeah..
# kaniini that domain isn't google.com
# kaniini anyway
# kaniini i will just say that since AP does not allow this
# kaniini you are screwed
# kaniini and then those users will not use pleroma
# kaniini because i give up
# kaniini this isn't worth my time or your time
# kaniini and in 2 years when pleroma is using diaspora protocol to federate, nobody will be surprised
# kaniini i was going to require that the actor be reachable at the main domain somehow
# kaniini but really, it's not worth it
# kaniini "alsoKnownAs": ["https://foohosting.com/~foo"]
# kaniini and then if https://foohosting.com/~foo has the same ID
# kaniini then it is allowed
# puckipedia I was actually kinda surprised AS2 didn't have any predicate like that
# kaniini cwebber2 yes
# kaniini but
# kaniini again
# kaniini i just need this identifier standardized
# kaniini since W3C controls the AS2 vocabulary
# kaniini i am asking nicely for this
# kaniini i do not want it buried in some JSON-LD thing
# kaniini i want it in AS2 core vocabulary
# kaniini we are talking about
# 
cwebber2 kaniini: would it be, I fetch https://foohosting.com/~foo and have an alsoKnownAs that back-points at the other document?
# kaniini binding preferredHostname to a hostname mentioned in alsoKnownAs
# kaniini cwebber2 no
# kaniini cwebber2 in this case it would literally be
# puckipedia cwebber2: if I'm reading it properly, it'd be alsoKnownAs is just URLs, returning the same document as the main object's ID
# kaniini the same ID
# kaniini so we extend alsoKnownAs (as discussed at #300) to also be URIs that return the *same* actor
# puckipedia mm
# kaniini *you* don't have to worry about it
# kaniini i'm back to giving up
# kaniini reads up on diaspora protocol that already has this feature
# kaniini i consider it a feature that AP does not standardize email addressing
# kaniini i am not even requesting an extension to AP
# kaniini i am requesting an extension to AS2
# kaniini so i fundamentally do not understand why we need to discuss email-based addressing
# kaniini *you* use mastodon
# kaniini *you* already know how this works
# kaniini it is critical to users of pleroma
# kaniini that is not related to activitypub
# kaniini i just need the field
# kaniini we can figure it out from there
# puckipedia kaniini: you're not the only one implementing activitypub btw
# kaniini i already explained this: it is one of the domains that appears in alsoKnownAs
# kaniini as a *display hint*
# kaniini mastodon already implements this
# kaniini with webfinger
# kaniini you guys don't want AP servers to become married to webfinger, right?
# kaniini yes/no
# puckipedia <puckipedia> turns out "optional" is not that optional when all the implementations implement and expect it
# kaniini it is the addressing
# kaniini but i don't see how it is needed
# kaniini to be in activitypub
# kaniini i just need the field
# kaniini or more specifically, i just need to ensure the W3C will not collide that field
# kaniini if i have that, i can work this out with Gargron directly
# puckipedia kaniini: hm, so, hear me out:
{id: mastodon.example.com/~a, "alsoKnownAs": [example.com/~a], url: example.com/~a} -> use example.com# kaniini puckipedia except the mastodon users will have
# kaniini url: mastodon.example.com/~a
# puckipedia mmm.
# kaniini they want it to go to mastodon.example.com
# puckipedia kaniini: however, if Mastodon were to implement your suggestion, they'd have to redirect example.com/~a to mastodon.example.com/~a anyways
# puckipedia am I not mistaken?
# kaniini puckipedia the admin can redirect it in their apache.conf/nginx.conf with accept activity+json
# kaniini just as they redirect .well-known right now
# puckipedia kaniini: mm. feels kinda icky to only redirect as2
# kaniini meanwhile, pleroma is failing to get users who want this mastodon feature
# puckipedia cwebber2: also. bridgyfed still uses the webfinger thing
# kaniini i just want an OPTIONAL DISPLAY HINT like preferredUsername
# kaniini i give up
# kaniini it's not important
# kaniini "don't use webfinger", yet no help with not using webfinger
# kaniini thankfully i do not believe in webfinger
# kaniini otherwise i would just do what mastodon does -_-
# puckipedia cwebber2: it uses existing :handwave: to find the purpoted ID of @alice@social.example, which then contains a referral to an URL on social.example, which redirects back to the original ID to prove ownership
# puckipedia no
# puckipedia handwaving is webfinger in this case
# puckipedia but it could be any protocol that does this mapping
# kaniini yes, we have established that pleroma will use webfinger to bootstrap it
# kaniini that's not the point
# kaniini pleroma does not actually use webfinger to do the user@domain mapping
# kaniini we use preferredUsername for this
# kaniini which is what the AP spec says to do
# puckipedia well, it's heavily implied
# puckipedia cwebber2: webfinger is only used to establish that alice@social.example's ID is probably at ap.social.example/~alice
# puckipedia you webfinger social.example
# kaniini cwebber2 if i do what mastodon does
# kaniini cwebber2 then pleroma becomes married to webfinger
# kaniini right now
# kaniini you can run pleroma with webfinger completely disabled
# kaniini (this involves going deep into the config system, but it is possible)
# puckipedia I don't evne have webfinger in kroeg :D
# puckipedia cwebber2: s2s
# puckipedia I assume
# kaniini pleroma s2s does not use webfinger at all
# puckipedia like, no @a@b anywhere
# kaniini this is for c2s
# kaniini anyway
# kaniini my point is
# kaniini right now
# kaniini you can run pleroma with webfinger completely disabled
# kaniini and get generally what you would expect with @ addressing
# kaniini yes
# puckipedia well, you wouldn't be able to resolve new webfinger-style references I guess?
# kaniini so
# kaniini what you do is
# kaniini you click ADD USER
# kaniini and then you put in the URI of the user
# kaniini and then it will set up a @-address for them
# kaniini based on preferredUsername
# kaniini and the domain
# kaniini ok, yes, i agree that you could have that, but pleroma uses mastodon/gnu social APIs right now, not c2s
# kaniini look, i don't care what the field is called
# kaniini this XEP stuff scares the bejesus out of me
# saranix I think this obsession with "email-like addressing" is wholly unhealthy. It flattens zooko's triangle into a pancake. Human-meaningful and decentralized are supposed to be 2 separate corners. To me 'My friends name' is human meaningful *NOT* 'myfriendsprefferedshortname1975'
# nightpool[m] mm
# nightpool[m] that's you, I guess.
# nightpool[m] people on the internet are very used to usernames.
# saranix directory services. a look up. hell, we *are doing a lookup anyway*. Might as well stop flatting things and breaking everything.
# puckipedia saranix: note, we're actually doing this
# puckipedia at least the undoing email like addressing
# puckipedia piece by piece
# saranix plus, I'll just add, zot. nomadic id. 'nuff said
timbl joined the channel
# kaniini nightpool[m] would y'all be opposed to using something like preferredHostname instead of the webfinger hack
# saranix +1 alsoKnownAs
# kaniini saranix i agree fwiw, but i also have users to satisfy
# kaniini some of us are actually trying our best to make use of this stuff in the real world with real people
# kaniini and *they* want email-like addressing
# saranix fwiw, if the point is to emuklate email addressing then efforts should be made to emulate it's lookup as well. MX records are a thing.
# kaniini we do make efforts
# kaniini that's not the point
# saranix I don't think it's true that real people in the real world *want* email addressing. I think it is that they are just stuck thinking it is the only possibility and they don't know any better (yet). Education and providing alternatives can help.
# puckipedia ehh
# saranix You also have to be careful about giving the public what they *say* they want. What they think they want is daddy corporation manufacturing a feed for them.
# saranix "Users don't see the connection between their choices and the pain they are feeling. I do." - RMS... possibly paraphrased wrong