@evan Yeah. None of these things are immutable. When the next one goes, it'll be so much nicer if there's an off-ramp to another service because of federation. Saves you starting over, while looking glumly at a perfectly useless 700mb export from Twitter.
@evan the problem ist not the commercial part per se. The problem is the monopolistic and billionair part. They will embrace, extend, extinguish If they can because there unlimited ressources and we should give them the hardest time possible.
There were some concerns that posts by people on their own servers would be used for advertisement, abused, indexed, datamined, etc. by commercial services connected to the social web.
That would be bad. You should have control over that. Granting a person on a server the right to read or view your posts should not grant that server's operator a right to use your content for whatever they want.
We should have better support in ActivityPub for saying what you do or don't permit with your stuff.
@grin yeah, and there are still some pretty big restrictions on what they can do with it, just like any other content you publish on the web. Just because it's free to read, doesn't mean that it's free to copy anywhere and everywhere. It's easy to forget!
@evan One shall differentiate between what's doable and what's legal.
What I meant was "doable", what you seem to describe is "legal", but then, legally the server admin cannot do "whatever they please" unless it's written in the ToS.
@grin right. I guess it comes down to whether the lawyers at the company in question know about the problem, have the agency to stop it, and/or bother to do so. After that, it comes down to action in the courts by rights groups, or by competitors.
@evan In my experience sometimes it simply depends on the decision whether a company does ethical moves or not. I mean I do know I'm an idealist, but I know various (European) companies speficially deciding against legal but unethical practices.
@tony@evan Thou Shalt Not Generalise.
Even most anecdotically evil companies are not really evil and often act on protect the users' rights, however surprising it may sound.
And yes, there ARE evil companies. Often not those in the spotlight though.
@tony@evan You're not from the US so I guess it's not that bad there where you live. Indeed in the US they seem to have a more profit oriented mindset (in my experience).
@evan
> You should have control over that. Granting a person on a server the right to read or view your posts should not grant that server's operator a right to use your content for whatever they want.
And how would you enforce that? DRM? Public content on the internet can and will be "digested", no matter the creators intent.
@evan
I was thinking along the lines of a technical solution. Prevention is better than reaction.
> people have successfully sued e.g. Google
While this is technically correct, it is a misleading statement. Predominantly, other companies or institutions sue google; Occasionally individuals (with varying success). Our justice systems require time and money - two commodities, that (and I think you're aware of that) aren't exactly evenly distributed. Things like class-action lawsuits do not exist in most countries. Even if people are theoretically/officially protected by law, the majority of people aren't in a position to enforce that in our justice systems.
TL;DR: If you do not enforce peoples rights preemptively with a technical solution, they will be violated and most people can't do anything about it.
@evan I'm referring to the fact many services reserve the right to make up arbitrary data structures and meaning "on my behalf," when they could be using interoperable linked data.
I also strongly support people who want to control who has access to their stuff, and don't want their own instances to federate with commercial services or proprietary software services. That's why we use open standards and open source software; so everyone has that level of control.
@mlinksva@evan@ben@mattl@nyergler@rheaplex Greetings 👋 This summer I'm working with a GSoC contributor to re-implement RDF/XML. That will provide the base for both updating our use of RDF/XML and extending the machine readable layer to include JSON-LD. I was going to focus on user-facing documentation for using JSON-LD and schema.org. I would love to hear more about what you're imagining, Evan.
@TimidRobot@mlinksva@ben@mattl@nyergler@rheaplex We use JSON-LD for Activity Streams 2.0. It would be useful to have a standard way to include CC license information in the Activity Streams data. For example!
@TimidRobot@mlinksva@ben@mattl@nyergler@rheaplex I could do the conversion to JSON-LD myself, or someone else involved in ActivityPub could do it. It would be neat to have it at the creativecommons.org/ns/ URL.
@evan@cwebber JFYI the vocabulary has never really been useful, outside of a marketing talking point, and making things more complicated inside CC (sometimes useful, thwarting stupid ideas). I'd stick to dct:license and iff that proves to be useful, think about more.
@evan Voted “somewhat disagree” because I think the federated model still needs further development to mitigate issues of scale and performance, and I don’t think we should be locked into one protocol. But ActivityPub compatibility should be a goal even if it’s a new system, if possible.
@Green_Footballs@evan I think the correct way is to make the protocol part a module. If in time it has to change to something else it's easier to change the module and have the comms work the same internally.
@evan I would reframe as "All social software should support RSS" because IMO that is a better common denominator and easier to both implement and consume.
@John but if you split that population in half, with each half using an incompatible protocol, then the value of each network is (N/2)^2 or N^2/4. The total value is N^2/4 + N^2/4 or N^2/2 .
That means with the same number of people, the total value of the two protocols to them is HALF what it would be if they were using the same protocol.
@John If you build your protocols to be extensible and backwards compatible, like ActivityPub is, you can have lots of innovation and still keep everyone on the same network.
@John When you divide up your population of users, you're also dividing implementers, documenters, funders, supporters. Each network has fewer and fewer people working on it.
@John protocols aren't like products in a marketplace. Competition doesn't make them better for everyone. Cooperation makes them better for everyone. Competition should happen at the level of implementations, not protocols.
@evan I guess I could mention that sometimes the network effects were too great. Not every old standard is with us because it is beautiful. I think everybody accepts that email is a hella mess.
@John@evan Oh, I understand when new standards are needed, but there's also plenty of examples of TOO many standards and then nothing gets adopted. If every major manufacturer of a device creates their own standard, there is no standard (in protocols and hardware). If you're advancing what is done (and it can't be done with a standard, and it doesn't make sense to extend an existing standard) that is one thing... but two, competing standards for the same thing 🤷
@evan "somewhat agree" because it feels very against the FLOSS ethos to force/coerce folks to join the network when they don't want to, but it sure would be nice to see
@lispi314 I doubt that p2p was even considered as a use-case for ActivityPub as the protocol specifies only client -> server, and server -> server intreactions.
The best one can do is to use the ActivityStreams vocabulary with a p2p logic, but that would not be related to AP at all (except in the fact that interop would be relatively easy due to using the same data types).
@lispi314 (and if you'll excuse me a small impertinence) I'll be waiting with bated breath your contributions to a P2P protocol based on ActivityStreams.
@mariusor oh, I was constraining myself to a design that would implement AP as specified, and that could interact with client-server systems like Mastodon without requiring any changes!
@evan so a hybrid system where there would be an ActivityPub according to spec part and a p2p part that deals with the other peers directly... that's interesting, I can't say I thought about it like that.
@evan so a hybrid system where there would be an ActivityPub according to spec part and a p2p part that deals with the other peers directly... that's interesting, I can't say I thought about it like that.
@mariusor The Zot implementations are not p2p, but they follow this principle: Zot itself uses ActivityStreams and is as ActivityPub-like as possible while implementing its own network with its own requirements, and then a server server you choose acts like your home server toward the wider Fediverse.
@clacke even though I've interacted with Mike since I joined the Fediverse, I never really got to look into Zot at all in all this time. I feel somewhat bad, because it has a lot of good ideas.
I had a single-user Fedi instance for awhile, but ended up using social.coop more, so something crashed in the implementation and I have not fixed it. But it did work, and did federate, and I might have talked to some of you from there once upon a time.
@mariusor@evan I do indeed doubt that it was considered. Nevertheless, DIDs could work (and then you have an implementation nightmare of adding all the protocols to AP implementations) as would a simple full-mesh single-user approach and hosting them all on something like #Tor or #I2P to handle the routing issues (and you get improved privacy & anonymity for free, with very few software modifications needed since most implementations support outbound HTTP proxying).
@evan Some sort of federation protocol, basically yes. ActivityPub per se, only as long as it remains the gold standard — and even then, there's room for experimenting with different protocols.
@evan “strongly disagree” because nothing is absolute and choice is paramount. Aim to use the best tool for the job at hand rather than enshrining a one true tool for all things.
> SHOULD
> This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
@evan "somewhat agree" for now. Right now there are important use cases it can't do involving privacy, but with e2ee coming up (including for group messaging?), I would change to "strongly agree".
@evan Primarily user data concerns. It's probably overzealous in that regard, I just would prefer no chance of monetization of existing user content that may have been generated on a Mastodon instance.
@evan I am generally supportive of collaborative & collective efforts - hosting isn't free and sysops don't look to make (too much) money from these operations. That's probably particularly true at scale where diskspace starts to become an issue. I'm mostly weary about existing (or forthcoming) platforms that may be looking to access and monetize Fediverse user data in some fashion - eg Meta, Google, Twitter, BlueSky; platforms whose existence attempts to profit from the users.
I personally want to make a wiki that's federated (to @TerryHancock's point),
and I can see that sometimes the medium isn't meant to be a forum/blog (like mastodon/lemmy/peertube are), and instead is meant to be a private conversation (like email) or a live chat (like IRC - even though this is sometimes archived IRC makes for awful threading / locating things) - so I see some of @josephholsten 's points
If it's an online conversation, should it take yet another account / should it be behind yet another wall?
if it's an online forum, can it instead be a public wiki?
sometimes things bleed into either personal and highly specific, to forum-ish / subscription-based / discussions, to highly static / wiki like research.
@risottobias@evan@TerryHancock Hrm, you’re making me think about how to identify if something is poorly suited by use case, not just by pre-existing solution/protocol.
My first thought was: Identifiers! ActivityPub posts should have distinct URLs, it’s should be like a bidirectional RSS feed.
But… emails have message-ids. Certainly individual messages have their own encapsulation in IRC & XMPP.
So I’ve painted myself into a corner.
@josephholsten@risottobias@evan@TerryHancock
The issue with identifiers is how they are allocated. If domain-related what happens if user or their content moves to a different domain? Change every identifier to new location breaks history, almost anything else requires a central registry.
Random uuid time-based works for small numbers but doesn't scale.
Including every option creates uniqueness but massive overheads.
I'll join you in the corner if I may.
@TerryHancock@risottobias@evan But those are the collections, not the individual posts, right? I’m trying to imagine an entire repo or library as a single activity and it making me silly.
I don't know ActivityPub or physics well enough to say if AP may do for software-based comms to the extent that sound waves and photons do for verbal and visual comms. Nor if I've even scoped the real-world protocols fairly there, or if AP is closest.
I reckon the work involved in adding support for protocols may not yet be little enough to reasonably say all social software should do it for one.
@TerryHancock@evan I hope we get federated wiki-hosting because right now, either you need a different account for every wiki, or we rely on centralized wiki-farms like #FandomWiki. Ideally, either #MediaWiki itself would gain federation support or new wiki software would allow importing a MW database.
However, I am now going to move the goalposts and say that there is another reason I want federated wikis: cross-wiki transclusion. Currently you can "transclude" an article or section into another article on the same wiki, but AFAIK there is no way to transclude an article from one wiki onto another wiki.
Times this would be appropriate would be if two or more wikis had distinct but overlapping subject matters, such as the wikis that make up #NIWA. For example, it might be appropriate for the Super Mario Wiki article on Kirby: https://www.mariowiki.com/Kirby
To transclude some parts of an article from Wikirby or SmashWiki, in a way so that edits to the original page or section on Wikirby automatically carry over to the page on Super Mario Wiki.
Obviously care would need to be taken to avoid mixing incompatible licenses.
Add comment