Post
(1/2)
@mick_collins
> someone could write a front-end that calls those apps as if they were the same app, and the end user wouldn't need to know
Ooh, you're wading into murky waters here Mick ; ) Here be (komodo) dragons!
Putting aside the messy details, you're right that one app could present a unified interface on top of a bunch of different components. In fact, most apps do that, we're just so used to seeing certain features bundled together that we don't notice.
@benpate
> We could probably rebuild most of Discord's features as an Emissary inbox without doing a lot of back end code
One way to rapid prototype this would be to cheat. Copy as much as Discord's HTML/CSS/JS as you can get hold of. Chuck it in a private repo, accessible only to you/ your team.
Then you only need to build a layer of scripting glue and gaffer tape between that and an existing AP back-end (#Emissary, @Bonfire, dealer's choice). Published under a free license.
(1/2)
@strypey just commenting about copying JS. It might be helpful to be mindful that some users disable all JavaScript, like in Tor Browser. :)
@crft
> It might be helpful to be mindful that some users disable all JavaScript
I use NoScript, so I'm aware. But I doubt there's a big overlap between people blocking JS and people depending on Discord and needing a replacement ; )
Also these 2 posts were proposing a rapid prototyping experiment. A proper long term Discord replacement for the fediverse would need native apps etc.
After a few days/ weeks of furious hacking, you'll either give up in disgust and tombstone your repo, or a get a PoC working. If you do, celebrate and announce the fact.
Then you can recruit web/app designers who've never had access to the private repo (with the Discord layout code). They can then build Free Code interfaces on top of your glue and gaffer tape layer. Voila, a fully libre service with all the key features of Discord
Rinse, repeat for other DataFarms we'd like to replace.
(2/2)
@strypey
I Am Not A Coder, but @laurenshof pointed out that all the pieces that make up a Discord replacement are already in the Fediverse (article here: https://connectedplaces.online/reports/fr153-what-does-a-discord-replacement-look-like/), just not in one app. It occurs to me that someone could write a front-end that calls those apps as if they were the same app, and the end user wouldn't need to know
(1/2)
@mick_collins
> someone could write a front-end that calls those apps as if they were the same app, and the end user wouldn't need to know
Ooh, you're wading into murky waters here Mick ; ) Here be (komodo) dragons!
Putting aside the messy details, you're right that one app could present a unified interface on top of a bunch of different components. In fact, most apps do that, we're just so used to seeing certain features bundled together that we don't notice.
(2/2)
But the devil is in the details. Specifically, what kind of plumbing is the most efficient, most maintainable way to connect all the bits together?
Up until 2020, when it died without warning, I had the #Disintermedia blog and wiki on CoActivate.org. A site based on OpenPlans, a Free Code project creates by welding together WordPress and a bunch of other software with a Python framework (Django, I think?). The UX was pretty good for the time, but performance and maintenance were hell.
@benpate @strypey@mastodon.nzoss.nz I'm building Shoot, a discord-like federated instant messenger with activitypub! I would always appreciate any help with development, my pins has any more info as well
@maddyunderstars Looks cool! I'm starring and following your work.
It looks like you're using Typescript. All of my E2EE work is in Typescript, so there's a good chance you could use the library I'm making when you want to do encrypted groups.
Let me know when I can help :)
@benpate Thanks! Your e1ee library will be helpful! Is it public right now? I had started playing with libsignal after seeing @HolosSocial use it
Sorry I missed your note until now. My work is still very much "in progress" but it's all public. For now, you can see it here: https://github.com/EmissarySocial/emissary/tree/dev-e2ee/_embed/templates/user-conversations/resources/app
... but it will likely me moving to a better home later this week :)
#Roomy currently based on AT Proto but looking to add #ActivityPub soon
https://itsfoss.com/roomy-discord-alternative/
Hey, this is pretty interesting. Thanks for sharing!
That would be really cool if they can support Bluesky and ActivityPub at the same time.
The article on the website makes it seem like you’re only signing in with your ActivityPub identity though?
Otherwise, “Fediverse” client support is limited to the Mastodon API, or oft-unimplememted C2S API.
I’ll definitely keep my eyes on this one!
@benpate @klu9 @strypey ATProto is used only for authentication, optional integrations, and optional backups.
We have our own somewhat generic event streaming server that we use for chat spaces, where each chat space could be migrated to another server without the permission of the current host.
It's "federated" in that each chat space will be able to be hosted on a different server and the client will still be able to join them all from the same app.
We figure we don't need to replicate the chats to different servers, we just need to forward requests to the servers hosting the chat spaces that you've joined.
There's more technical details in this blog post and I'm always open to questions!
@zicklag
> I'm always open to questions!
How far off the mark was I in this pair of posts, about how Roomy uses ATProto and what that suggests for how it might use ActivityPub?
https://mastodon.nzoss.nz/@strypey/116066950694720465
> we don't need to replicate the chats to different servers
So "channels" and "servers" (as Discord uses these terms) would be tied to the originating server, like MUC in XMPP? Not replicated using the data storage of the participating accounts, as Matrix does?
Roomy does have a client and a server. The server has it's own protcol that isn't Roomy specific.
If we let you login with Mastodon it would just be for login still keep all of the data hosted on our server and wouldn't need to implement any Mastodon / AP APIs.
We do use the PDS for some storage / integrations, but once we get a tiny new feature in our server those can all be optional, and all the we need can be hosted on our server.
(1/2)
@benpate
> you’re only signing in with your ActivityPub identity though?
The article is light on specifics, but it seems like Roomy is a client app, not a server+client app like Mastodon. So in ATProto jargon;
https://dustycloud.org/blog/how-decentralized-is-bluesky/
... Roomy is an AppView, using the PDS for a logged in ATProto account as a data store (not sure if or how it uses Relays).
(2/2)
If Roomy enabled signing in with a fediverse account as an identity, there's no PDS to use for data. So I'm guessing the plan is to implement the Mastodon API, enabling Roomy to act as a fediverse client, and use a logged in account's home service as the data store?
What would be really intriguing is if Roomy borrowed from the @activitypods approach, allowing a fediverse account to be used as identity, with a Solid pod as the data store.
@strypey @activitypods Roomy implements its own storage. #ATProto is only really used as an identity / sign-in layer.
@FenTiger
> Roomy implements its own storage. ATProto is only really used as an identity / sign-in layer.
@zicklag's reply to @benpate suggests it's both/and;
https://mastodon.social/@zicklag/116069496831677674
The Roomy server has a copy of the data, and backs it up to PDS for people logged in with ATProto accounts. Not sure what implications this has for people logging in with ActivityPub accounts. But Solid pods could, in theory, be used like PDS a la @activitypods.
